Hi Mark, Lars
sound { compatible = "simple-audio-card"; ...
cpu { sound-dai = <&rcar_sound 0>; }; codec { sound-dai = <&ak4643>; };};
(snip)
There's two separate things here. One is how the code is implemented (which does look very much like it should be doing DPCM) and the other is how the DT binding looks - the DT binding is supposed to be a hardware neutral thing and not depend on Linux implementation details. If you've already got the hardware described well enough to discover everything then that generally indicates that the DT binding should not need to change.
In my case, I need DPCM if CPU want to use "sampling rate convert", otherwise, I don't need it. So, DPCM <-> non DPCM switching happen if DTS has sampling-rate-convert = <xxxxxxx> or something like that. Does my understanding correct ?
I re-considered about above, and checked current code. If my above understanding was correct, simple-card driver needs many patches to support it. And, it is not easy
I want to synchronize basic agreement before starting it. Otherwise, it is easy to reject my many weeks work, and I don't want it. # 1st simple-card DT support used 1 year...
My understanding is below. It is good match for my current purpose, and "sampling-rate-convert feature via DPCM" can be standard on simple-card. My concern is simple card code will be not simple...
-- non DPCM ----
sound { compatible = "simple-audio-card"; ... cpu { sound-dai = <&cpu-dai>; }; codec { sound-dai = <&codec-dai>; }; };
same as current style
-- DPCM ----
sound { compatible = "simple-audio-card"; ... cpu { sound-dai = <&cpu-dai>; }; codec { sound-dai = <&codec-dai>; fixed-sampling-rate = <44100>; }; };
DPCM FE/BE will be
FE cpu : cpu-dai codec : dummy
BE cpu : dummy codec : codec-dai
required route will be created automatically but, it needs "enable DAI name on DAPM route" method anyway