Hi Lars
Thank you for your feedback
> > int snd_soc_runtime_set_dai_fmt(xxx)
> > {
> > ...
> > /* Flip the polarity for the "CPU" end of a CODEC<->CODEC link */
> > if (cpu_dai->codec) {
> > ...
> > }
> > ...
> > }
(snip)
> This is for CODEC<->CODEC links where no CPU DAI is involved and the
> "CPU" side of the DAI link is actually a CODEC.
Wow !!
> Ideally we'd make the DAI links agnostic to what is connected, e.g. it
> shouldn't matter what type is connected to what side. But that does not
> work since things are anti-symmetric between CPU and CODEC DAIs. On
> CODEC DAIs the capture stream is output, on CPU DAIs the capture stream
> is input, similar thing for playback. So we need to know whether the DAI
> is a CPU DAI or a CODEC DAI.
>
> Fixing this at this point is near to impossible since it requires
> invasive changes to all existing drivers. So we need this code and can't
> drop it.
>
> The best we can do is try to come up with a generic interface that is
> DAI type independent and recommend this interface for new drivers.
Hmm...
OK, now, I'm investigating ALSA SoC struct connection.
And yes, existing code has deep relationship each other.
Thus, fixing/droping seems very dificult...
I think each struct has random pointer connection which doesn't care
about ALSA SoC's hierarchy.
I would like to indicate my opinion here.
My strange point are...
1. snd_soc_pcm_runtime has pointer to Card/Codec/Platform, but no CPU
2. snd_soc_dai has pointer to [component] and [Codec]
[component] is its parent, [Codec] is maybe Hack
3. [component] has pointer to [card] and [Codec]
[card] is understandable, [Codec] is maybe Hack
It seems many struct would like to access to [Codec], thus, each struct has
codec pointer (as hack ?), but it is ignoring ALSA SoC hierarchy.
It will be more clear if...
IDEA 1
Each component (= CPU/Codec/Platform) has pointer to Card now.
How about Card has pointer to each component ?
if so, we can access to every struct.
Card -> CPU/Codec/Platform, CPU/Codec/Platform -> Card
Then, we want to have component related macro/flag
#define component_is_cpu(component) (component->flag & COMPONENT_CPU)
#define component_is_codec(component) (component->flag & COMPONENT_CODEC)
#define component_is_platform(component) (component->flag & COMPONENT_PLATFORM)
#define component_to_cpu() container_of(xxx)
#define component_to_codec() container_of(xxx)
#define component_to_platorm() container_of(xxx)
IDEA 2
if IDEA1 was OK, snd_soc_pcm_runtime already has card pointer.
This means snd_soc_pcm_runtime can access to every component struct.
snd_soc_dai has its parent component.
This means snd_soc_dai can access to Card, and Card can access to every component.
And then, cpu_dai->codec has no issue if we can use component_is_xxx() macro ?
- if (cpu_dai->codec)
+ if (component_is_codec(cpu_dai->component))
If IDEA1 / IDEA2 are OK, we can cleanup each struct,
especially hack-able random pointer ?
Best regards
---
Kuninori Morimoto
