Re: [PATCH] [RFC] ASoC: Conditional PCM support

[Mark Brown <broonie@xxxxxxxxxx>]

On Fri, Sep 13, 2024 at 01:53:41PM +0200, Pierre-Louis Bossart wrote:
> On 9/13/24 12:59, Cezary Rojewski wrote:

> > Instead, I'd suggest to have a second, separate DPCM implementation
> > present next to the existing one and have users opt in during a so-
> > called deprecation period of the existing one. Once certain amount of
> > time passes, switch all of them. Clean slide also makes it easier for a
> > developer to be creative.

> > Do you view the second option as viable?

> Classic problem without a good solution. In practice new features or
> corrections get added to the 'old' framework and the new one is not used
> by anyone just yet so it keeps running behind in terms of
> features/maturity. And due to limited validation resources or limited
> access to a wide variety of hardware, no one is quite ready to enable
> the new framework on 'old' platforms because that would break quite a
> few devices.

Yeah, there's no idea way of doing things here.  I do think that keeping
things going in parallel is probably the most viable way of doing
things.  You'd need at least one lead platform using the new stuff, and
probably each platform would have a flag day to transition.

I'm a little more optimistic than Pierre about making progress,
hopefully things would be sufficiently nicer that once there's something
to build on it'd start to get more attractive to do the incremental
investments needed in the core to enable more platforms, and reduced
maintainance costs get more appealing.  This approach has worked for
other things (regmap springs to mind, and if you look at some of the way
API transitions are done in the memory management and arch code there's
a bunch of this going on) though it's rarely fast.

> The other problem is that the 'switch' would mean a compatible solution,
> but the problem is to get rid of the very notion of front- and
> back-ends. Existing users of DPCM have undocumented hard-coded
> dependencies on the order in which callbacks are handled, it's not easy
> at all to change the routing engine.

Each platform is going to need to be pretty careful with the conversion
and validating that things work.  There are some simpler ones which will
probably have an easier time of it, though.  There's some of them like
Kirkwood that are just at the lower end of needing DPCM support at all,
and others that didn't upstream so much stuff yet so there's less
knowledge embedded in the upstream code.

Attachment: signature.asc
Description: PGP signature