On Thu, Sep 05, 2024 at 11:27:41PM +0000, Kuninori Morimoto wrote:
> > Yeah, at a super high level we want to be able to handle digital audio
> > with DAPM like analog audio, the main thing is we'd need to propagate
> > digital parameters along as well as just on/off status, and support
> > conversions.
> Very rough speaking, we don't want to break existing connections
> (normal, DPCM, Codec2Codec, etc), and enable to use new style right ?
> Let's name current style as PCMv1. I think we want to grouping related
> things into one place, let's say soc-pcm.c, in roughly.
Well, long term we'd want to remove DPCM and CODEC 2 CODEC but kind of I
think.
> And make new style (PCMv2) at soc-pcm2.c, for example.
> Then, we can swtich v1 or v2 somehow, like below ?
>
> -------- soc-pcm.c -----
> struct pcm_connection pcm1_connection = {
> .ver = 1,
> .new_pcm = soc_new_pcm,
> ...
> };
> -------- soc-pcm2.c -----
> struct pcm_connection pcm2_connection = {
> .ver = 2,
> .new_pcm = new_pcm,
> ...
> };
> -------- soc-core.c -----
> if (ver == v1)
> connection = pcm1_connection
> else (ver == v2)
> connection = pcm2_connection
>
> - ret = soc_new_pcm(rtd, num);
> + ret = connection->new_pcm(rtd, num);
It's not clear to me if we'd need to specify things as an explicitly PCM
link, or if we'd be able to just use a DPCM route to link things and
then have be able to automatically configure the digital bits based on
capabilities of the things being linked. We would need to provide a lot
more information on the things being connected in order to do that, and
some of them would need digital operations. Ideally we'd be able to do
things in such a way that we can transparently transition the
implementation used for simpler existing boards without requring them to
be rewriten if they're not using one of the more complex things like
DPCM that we're trying to replace.
> We can create PCMv3, v4, v5... in the future if existing connection
> style was not good enough. ... well... this is almost "ideal" ;P
Doing things as described above means that there's much less information
in the individual drivers, just descriptions of what's connected to what
as much as possible. To a certain extent the fact that that's not the
case is kind of the problem we're trying to solve here.
Attachment:
signature.asc
Description: PGP signature
