On Mon, Feb 16, 2015 at 08:49:31AM +0000, Kuninori Morimoto wrote:
I want to create new sound card driver which supports DAPM. But I can't use simple-card driver for this purpose because DT binding issue. I guess, this new sound card can use/share simple-card functions.
Adding Jean-Francois who was looking at doing a refreshed simple-card using the graph bindings, and Lars who's been involved a bit as well.
OTOH, simple-card is not "simple" today :(
Basically, main purpose of simple-card / new sound card is binding CPU/Codec settings to ALSA SoC framework. But we have many pattern for it. From DT bindings point of view, we can/should use same DT bindings for same settings.
Now, simple-card is supporting
- single CPU/Codec
- multi CPU/Codec
- more feature...
My opinion is that complex code has un-understandable bug. So, how about simplify simple-card, what do you think about this idea ?
Obviously cleanups are good, but we can't break compatibility with old bindings.
We separate current simple-card to common parts, and, simple-card specific parts. basically, common parts controls DT bindings and ALSA SoC settings. sound card specific parts cares each own feature.
Bits of it are already written like this so more librification seems like a good approach, it also means that when someone has a genuinely board specific driver they can reuse as much code as possible.
- common : basic common functions
- simple-audio-card : existing driver, keep as-is for compatible reason
- single-audio-card : single CPU/Codec sound card. simplified from simple-audio-card
- multi-audio-card : multi CPU/Codec sound card. simplified from simple-audio-card
- fixrate-audio-card : new sound card same as single-audio-card, but it needs sampling-rate-convert via DAPM,
- chain-audio-card : DAPM card (?)
- ....
My idea is taht we can replace current "simple-audio-card" to "single-audio-card", or, "simple-audio-card" to "multi-audio-card" on DT.
I think this would make things more complex since we'd inevitably end up with combinations of the features that need supporting together and it seems like there'd be poor code reuse. We do also still have to support the existing binding.