On 07/26/2016 07:41 AM, Kuninori Morimoto wrote:
Hi ALSA SoC
My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform) doesn't care about "unbind/rmmod". For example, if someone unbinded/rmmoded "Codec", Card or other modules doesn't know about it. Thus, user can continue to use this sound card, and kernel will be Oops.
So, I would like to solve this issue, and for this purpose, now I'm investigating about ALSA SoC structures. It is now super complex, and I noticed that it is having duplicated struct members.
If possible, I would like to cleanup this issue.
During this investigating, I noticed 1 strange operation
${LINUX}/sound/soc/soc-core.c :: snd_soc_runtime_set_dai_fmt
int snd_soc_runtime_set_dai_fmt(xxx) { ... /* Flip the polarity for the "CPU" end of a CODEC<->CODEC link */ if (cpu_dai->codec) { ... } ... }
struct snd_soc_dai { ... /* parent platform/codec */ struct snd_soc_codec *codec; struct snd_soc_component *component; ... }
According to snd_soc_dai, *codec is its "parent". I wonder does "cpu_dai" really can have "codec" parent ?? I think this is not correct, and we can remove this operation ?
This is for CODEC<->CODEC links where no CPU DAI is involved and the "CPU" side of the DAI link is actually a CODEC.
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.