[alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec

[Kuninori Morimoto]

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