Re: ASoC: soc-pcm2.c ?

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 03/02/2026 18:18, Mark Brown wrote:
> On Tue, Feb 03, 2026 at 09:45:50AM +0200, Péter Ujfalusi wrote:
>> I'm not sure what you mean by this, but since there are several codec
>> vendors and they produce different codecs, they do need to have
>> different drivers. Some needs more complex, some simpler and DAPM
>> provides the functionality for the developers to not care about the
>> things that are generic (sequencing, path finding, register/bit flips, etc).
> 
> AIUI the issue referred to there is on the SoC side - DPCM doesn't
> support SoC drivers as much as CODEC drivers due to the lack of
> framework features for dealing with digital parameters.

That is true, within SOF framework we have our own implementation of
passing PCM parameters along the path and modules can change those -
8KHz mono from aplay leaves the DSP as 48KHz stereo and from there it
goes to the codec.
We pigyback on DAPM/DPCM for some graph work.

>> I'm not sure if I read this right, but the proposal is to create a
>> parallel and incompatible susbsystem?
>> How would existing codec drivers be used in there?
>> The promise of ASoC is that an OEM could pick any SoC and wire it up
>> with any codec and that will 'just work'.
> 
> AIUI the idea is to only rework the SoC side.

Up to DAI, including DSPs?
SoC side is in simplest term is platform (DMA) + DAI, when it becomes
more interesting/challenging is when you have platform (DMA) + DSP + DAI
on the SoC side - and then another DSP on the codec side.

>>> If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
>>> file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
>>> People can easily try/test it by just including it in your DTSI file.
>>> No HW / no implementation is needed for testing. And I think it can be good
>>> sample code to create new CPU driver ?
> 
>> We use ASoC on non OF machines as well, I understand that the current
>> users will not be affected, but having a parallel ecosystem sounds a bit
>> scary proposal for ASoC to move forward?
> 
> We'd have to work out some way to flip the switch for ACPI systems at
> some point, I guess there it'd be either a command line parameter or a
> build option (which we'd probably end up with at some point for DT
> systems once things are more ready).

My concern is more of a parallel and incompatible ecosystem which might
force duplicated drivers. This is what is not clear and could cripple
the benefit of ASoC and we are back in sort of pre ASoC tightly
integrated world.

-- 
Péter