Hi Mark
If we're already specifying the DAI links for the (D)PCM code it seems like we shouldn't also have to put DAPM routes for them in DT as well.
Yes, and I think we shouldn't use anything except for datahsheet pin names in the devicetree routing, because otherwise we are leaking driver implementation details.
It came from snd_soc_of_parse_audio_routing() Do you mean this function itself is not good ?
That's intended to be routing analogue pins to each other, not for DAI links in DPCM - for DAI links we should be getting this information from elsewhere.
While I agree with the sentiment for this when it comes to DAIs we probably want to use the name the interfaces get in the documentation rather than pin names since they involve multiple pins working together.
Sorry, but what does your "interfaces get in the documentation" mean ?
If the documentation refers to the interface as for example "I2S0" then the DT should refer to it as I2S0 too.
Hmm... This means we need update DPCM interface ? In my understanding, DPCM needs DAPM routing information somehow in final stage. But, we want to specify it as "DAI link" like interface.
Now, I have many questions.
If my understand is correct, my prev patch is OK for "DAPM final stage", but we need wrapper for "DPCM interface" ? It will exchanges "I2S0" to "ak4642 Playback" internally. (And exchanges format too ?)
Is this needed as "DT interface" ? Can non-DT code use "ak4642 Playback" directly ? I'm wondering that some driver is using DPCM already (in non-DT) in upstream.
If we can use "I2S0" interface, it is understandable if FE/BE was
FE cpu: CPU-A codec: dummy
BE cpu: dummy codec: Codec-A
But, How about this case ?
FE cpu: CPU-A codec: Codec-A
BE cpu: CPU-B codec: Codec-B