* About ALSA SoC cpu/codec asymmetry
@ 2014-03-10 2:10 Kuninori Morimoto
2014-03-10 6:42 ` Lars-Peter Clausen
0 siblings, 1 reply; 6+ messages in thread
From: Kuninori Morimoto @ 2014-03-10 2:10 UTC (permalink / raw)
To: Mark Brown, Stephen Warren, Lars-Peter Clausen
Cc: Linux-ALSA, Simon, Liam Girdwood, Kuninori Morimoto,
Kuninori Morimoto
Hi Mark, Stephen, Lars
Now, ALSA SoC is using "component" style, and its image is like this.
ALSA SoC
- platform
- component (as CPU)
- codec
- component
It is still not symmetry, and confusable.
I guess this is understandable.
ALSA SoC
- platform
- cpu
- component
- codec
- component
If we add "cpu", it needs "cpu name", same as current "codec name"
on soc_bind_dai_link().
I guess it can keep compatible if it allows "NULL" name on "cpu name" at this point.
(but print warning ?)
What do you think ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About ALSA SoC cpu/codec asymmetry
2014-03-10 2:10 About ALSA SoC cpu/codec asymmetry Kuninori Morimoto
@ 2014-03-10 6:42 ` Lars-Peter Clausen
2014-03-10 7:03 ` Kuninori Morimoto
0 siblings, 1 reply; 6+ messages in thread
From: Lars-Peter Clausen @ 2014-03-10 6:42 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Kuninori Morimoto, Stephen Warren, Mark Brown,
Liam Girdwood, Simon
On 03/10/2014 03:10 AM, Kuninori Morimoto wrote:
>
> Hi Mark, Stephen, Lars
>
> Now, ALSA SoC is using "component" style, and its image is like this.
>
> ALSA SoC
> - platform
> - component (as CPU)
> - codec
> - component
>
> It is still not symmetry, and confusable.
> I guess this is understandable.
>
> ALSA SoC
> - platform
> - cpu
> - component
> - codec
> - component
>
> If we add "cpu", it needs "cpu name", same as current "codec name"
> on soc_bind_dai_link().
> I guess it can keep compatible if it allows "NULL" name on "cpu name" at this point.
> (but print warning ?)
There is already a cpu_name field for the DAI link struct and it is ignored
when it is NULL. See
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-core.c#n870
I have a patch that makes using cpu_name mandatory for new component
drivers. And then we can slowly start to convert old platforms.
- Lars
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About ALSA SoC cpu/codec asymmetry
2014-03-10 6:42 ` Lars-Peter Clausen
@ 2014-03-10 7:03 ` Kuninori Morimoto
2014-03-10 7:14 ` Lars-Peter Clausen
0 siblings, 1 reply; 6+ messages in thread
From: Kuninori Morimoto @ 2014-03-10 7:03 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Linux-ALSA, Kuninori Morimoto, Stephen Warren, Mark Brown,
Liam Girdwood, Simon
Hi Lars
> There is already a cpu_name field for the DAI link struct and it is ignored
> when it is NULL. See
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-core.c#n870
indeed
Thanks
> I have a patch that makes using cpu_name mandatory for new component
> drivers. And then we can slowly start to convert old platforms.
Nice !
Basically, my worry is cpu/codec "asymmetry" data structure.
(Maybe it came from "historical" reason?)
I would like to have new "struct snd_soc_cpu" and "snd_soc_register_cpu()"
instead of current "component" if possible.
It is understandable.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About ALSA SoC cpu/codec asymmetry
2014-03-10 7:03 ` Kuninori Morimoto
@ 2014-03-10 7:14 ` Lars-Peter Clausen
2014-03-10 7:20 ` Kuninori Morimoto
0 siblings, 1 reply; 6+ messages in thread
From: Lars-Peter Clausen @ 2014-03-10 7:14 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Kuninori Morimoto, Stephen Warren, Mark Brown,
Liam Girdwood, Simon
On 03/10/2014 08:03 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>> There is already a cpu_name field for the DAI link struct and it is ignored
>> when it is NULL. See
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-core.c#n870
>
> indeed
> Thanks
>
>> I have a patch that makes using cpu_name mandatory for new component
>> drivers. And then we can slowly start to convert old platforms.
>
> Nice !
>
> Basically, my worry is cpu/codec "asymmetry" data structure.
> (Maybe it came from "historical" reason?)
Yep.
>
> I would like to have new "struct snd_soc_cpu" and "snd_soc_register_cpu()"
> instead of current "component" if possible.
> It is understandable.
The patchset I'm working goes the other direction. The idea is to eventually
remove snd_soc_codec and only have snd_soc_component. With modern SoCs the
CPU side isn't just a dumb DAI anymore, but you often have signal routing
and mixing capabilities, sample rate converters, sometimes even a full DSP.
And then there are also those SoCs which have a DAC and/or ADC directly
built-in. This makes them complexity wise similar to the CODEC side and
having things like DAPM and our set of standard predefined kcontrols makes
it easier to manage them.
- Lars
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About ALSA SoC cpu/codec asymmetry
2014-03-10 7:14 ` Lars-Peter Clausen
@ 2014-03-10 7:20 ` Kuninori Morimoto
2014-03-10 7:56 ` Lars-Peter Clausen
0 siblings, 1 reply; 6+ messages in thread
From: Kuninori Morimoto @ 2014-03-10 7:20 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Linux-ALSA, Kuninori Morimoto, Stephen Warren, Mark Brown,
Liam Girdwood, Simon
Hi Lars
> > I would like to have new "struct snd_soc_cpu" and "snd_soc_register_cpu()"
> > instead of current "component" if possible.
> > It is understandable.
>
> The patchset I'm working goes the other direction. The idea is to eventually
> remove snd_soc_codec and only have snd_soc_component. With modern SoCs the
> CPU side isn't just a dumb DAI anymore, but you often have signal routing
> and mixing capabilities, sample rate converters, sometimes even a full DSP.
> And then there are also those SoCs which have a DAC and/or ADC directly
> built-in. This makes them complexity wise similar to the CODEC side and
> having things like DAPM and our set of standard predefined kcontrols makes
> it easier to manage them.
Ahh, very nice !
I can 100% agree to your idea :)
Sorry for my noise, I didn't know your (or ALSA SoC ?) plan
Please let me know if you need my help (maybe some test ?)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About ALSA SoC cpu/codec asymmetry
2014-03-10 7:20 ` Kuninori Morimoto
@ 2014-03-10 7:56 ` Lars-Peter Clausen
0 siblings, 0 replies; 6+ messages in thread
From: Lars-Peter Clausen @ 2014-03-10 7:56 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Kuninori Morimoto, Stephen Warren, Mark Brown,
Liam Girdwood, Simon
On 03/10/2014 08:20 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>>> I would like to have new "struct snd_soc_cpu" and "snd_soc_register_cpu()"
>>> instead of current "component" if possible.
>>> It is understandable.
>>
>> The patchset I'm working goes the other direction. The idea is to eventually
>> remove snd_soc_codec and only have snd_soc_component. With modern SoCs the
>> CPU side isn't just a dumb DAI anymore, but you often have signal routing
>> and mixing capabilities, sample rate converters, sometimes even a full DSP.
>> And then there are also those SoCs which have a DAC and/or ADC directly
>> built-in. This makes them complexity wise similar to the CODEC side and
>> having things like DAPM and our set of standard predefined kcontrols makes
>> it easier to manage them.
>
> Ahh, very nice !
> I can 100% agree to your idea :)
> Sorry for my noise, I didn't know your (or ALSA SoC ?) plan
>
> Please let me know if you need my help (maybe some test ?)
>
Sure, I'll keep you on Cc for the patches.
- Lars
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-03-10 7:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-10 2:10 About ALSA SoC cpu/codec asymmetry Kuninori Morimoto
2014-03-10 6:42 ` Lars-Peter Clausen
2014-03-10 7:03 ` Kuninori Morimoto
2014-03-10 7:14 ` Lars-Peter Clausen
2014-03-10 7:20 ` Kuninori Morimoto
2014-03-10 7:56 ` Lars-Peter Clausen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.