Hi Mark > > 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. This is my opinion, but even though if we can have new PCMv2 connections, I think we would like to keep existing DPCM / Codec2Codec as PCMv1 with no touch as much as possible not to break existing working system. Converting PCMv1 -> PCMv2 is maybe easy to break, especially non-normal connection. See below. > 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. Current DPCM vs Normal connections are using different ops, and Codec2Codec is using own style. Because of that, the code is very complex, and difficult to understand IMO. It is better to have an flexible and integrated system that assumes various connection methods from begining. In my understanding, for Normal connection, each driver is no need to update, or maybe small update only for PCMv2. But need to use new Card driver to use PCMv2 connection. For complex connection, like DPCM/Codec2Codec on PCMv1, needs to use new style on PCMv2, there is no compatible. I think if we really start to create PCMv2 connection, I think we can use test-component and new audio-graph-card3, and its sample.dtsi for test/try ? We can try various connections without physical board on it. This is also my opinion, but I don't think people will be happy if we adds new PCMv2 by using "change everything by big 1 patch". I think it's better to exchange ideas and opinions on ML, and make progress step-by-step. > > 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. Existing connection style has been created without considering to able to switch connection style of course. But I think we want to create such concept (= style version), and convert existing style into it (= PCMv1). In my quick check, compress / sof are deeply based on DPCM style, so I think using them need to use PCMv1 style. In other words, using/converting it on PCMv2 is maybe very difficult. So we want to have the concept which enable to use both PCMv1 and PCMv2 in the same time. Maybe same things happen on PCMv3 or later in the future (?). Above all are just my opinion, I'm not sure what is the good way. Thank you for your help !! Best regards --- Kuninori Morimoto
