[alsa-devel] simplify simple-card
Hi Mark, all
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.
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 ? 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.
I don't know about naming, but these audio card can use same bindings via common functions.
- 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.
Best regards --- Kuninori Morimoto
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.
Hi Mark
Thank you for your feedback
- 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.
Sorry, but I guess you are misunderstanding about my idea. My idea is that we create above sound cards, and use it by
sound { - compatible = "simple-audio-card"; + compatible = "single-audio-card", "simple-audio-card"; ...
If we can create simplified simple-audio-card (= here "single" audio card). we can use it, if not, we can use current simple-audio-card.
If it is difficult to keep compatibility between current "simple" and simplified card, can we create above new sound cards series ? Some of these functions are already created as common code (but no one is using it ?) new sound cards series can reuse it.
Best regards --- Kuninori Morimoto
On Tue, Feb 17, 2015 at 05:23:40AM +0000, Kuninori Morimoto wrote:
Sorry, but I guess you are misunderstanding about my idea. My idea is that we create above sound cards, and use it by
sound {
compatible = "simple-audio-card";
compatible = "single-audio-card", "simple-audio-card";
If we can create simplified simple-audio-card (= here "single" audio card). we can use it, if not, we can use current simple-audio-card.
If it is difficult to keep compatibility between current "simple" and simplified card, can we create above new sound cards series ? Some of these functions are already created as common code (but no one is using it ?) new sound cards series can reuse it.
I'm still seeing complexity here from the fact that we have to work out what combinations of features to support - if we're splitting things out then at some point we are going to have to have split code paths. It's possible I'm just not seeing the advantages here and that the code will make it clear what the benefits are but it doesn't feel like it's the way forwards right now.
Hi Mark
If it is difficult to keep compatibility between current "simple" and simplified card, can we create above new sound cards series ? Some of these functions are already created as common code (but no one is using it ?) new sound cards series can reuse it.
I'm still seeing complexity here from the fact that we have to work out what combinations of features to support - if we're splitting things out then at some point we are going to have to have split code paths. It's possible I'm just not seeing the advantages here and that the code will make it clear what the benefits are but it doesn't feel like it's the way forwards right now.
Hmm... OK I see Let's skip to simplify simple-card.
But, I need sound card which supports sampling-rate-convert via DPCM, and I can't use simple-card for it, right ? So, I need to create new sound card anyway. I need guideline about it. Can I create it in sound/soc/generic, or should I create it in /sound/soc/sh/rcar ? "rate-controllable-audio-card" What do you think about this name ?
Best regards --- Kuninori Morimoto
participants (2)
-
Kuninori Morimoto -
Mark Brown