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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
