Hi Mark
Thank you for your feedback
In my understanding, FE/BE connection is controlled by amixer, this means connection is not statically, but dynamically selected. (Or can we use statically linked FE/BE ?) I think, we can use above video-interfaces.txt idea for DT, but, not 100% good match for us ? Can you show me your DT binding idea for DPCM ? I can study it, and try to implement it.
This depends a bit on the hardware. If the audio block is one single IP to the rest of the system then DPCM probably ought to be totally transparent to DT and just look like a couple of DAIs attached to the IP or something. If the blocks are separate blocks that can be connected up any old way then it gets a lot more complicated. How does your system look?
I guess our IP is one of complicated system. Our system have many IP blocks which are called as SSI/SRC/CMD/DVC. So, in perfect world, I guess it will be
FE : SSI <-> dummy BE : SRC <-> CMD BE : DVC <-> codec
Or something like that, but, it is very complicate system at this point. I think we need 3 or 4 step for it.
Fortunately (?) these blocks are controlled in rsnd driver as 1 CPU today. So, I can say we can use it as
FE : CPU(*) <-> dummy BE : dummy <-> codec
(*) CPU includes SSI/SRC/CMD/DVC in rsnd driver
This is simple enough and good 1st step for DPCM support. I think our IP block needed these step
1. simple DPCM support on DT 2. sampling rate convert support on DPCM 3. multi FE/BE support on DT 4. rsnd multi block IP use multi DPCM
or (1 + 3) -> 2 -> 4 order How about this plan ?