On Tue, Jan 20, 2015 at 02:10:11AM +0000, Kuninori Morimoto wrote:
This really would be better done with DPCM with the userspace control being provided by the driver for the tuner or the machine driver and passed through to set the rate of the back end. Do you think that's achieveable (even if it's just a mostly dummy DAI here)? That way if this is used in a system with a CODEC with a real driver on the end of the link things should just work.
Can I confirm about this ? This means, we can..
- add "sampling rate convert" support on DPCM (= our "static" sampling rate convert can use it)
- add "sampling rate convert interface" support for userland on DPCM (= our "dynamic" sampling rate convert can use it)
I think this is achieveable.
Yes.
My concern about this is card driver with DT. I and Mark talked about it in LinuxCon before, and adding DPCM support with DT on simple-card is very difficult (= simple-card is not "simple" today...) So, I will create new sound card driver which includes DPCM DT support for this purpose. Then, should I create "renesas-sound-card" under sound/soc/sh ? or can I create "multi-card" (I don't know this is good naming...) under sound/soc/generic ? If we can select later choice, it will have very limited feature, but simple DPCM support
A Renesas card (well, a SoC specific name is probably better) seems OK, though as I said elsewhere collaborating on the generic graph work *might* be a good way forwards too. That definitely shouldn't be a requirement for getting things done though.