Message ID | 87o7m4lzl3.wl-kuninori.morimoto.gx@renesas.com |
---|---|
Headers | show |
Series | ASoC: replace dpcm_playback/capture to playback/capture_only | expand |
Hi Amadeusz Thank you for your review and feedback > patches look ok - I haven't run tests yet on v3, will try to get results > tomorrow. However looking at those assignments again, I wonder if we > really need them to be "negative" ones? Can't we just have some simple > fields like playback and capture (similar to dpcm_playback & > dpcm_capture from before). My concern is that having fields with "_only" > in name requires them to be handled properly - like in above code, while > having just "playback" and "capture" would be just simple assignment and > in the end a lot easier to understand. Is there any reason you chose to > use the *_only fields? Not a super big reason, but want to keep compatibility as much as possible. The driver which get effect from this patch is only DPCM user if it uses playback/capture_only. I think DPCM user < normal user. If we want to switch to use playback/capture flag from _only flag, we want have such additional patch-set instead of "change everything" patch-set ? And my understand is "playback/capture_only" are "option" flag, "playback/capture" are "necessary" flag. I like less "necessary settings" driver :) Thank you for your help !! Best regards --- Kuninori Morimoto
Hi Mark, again > > @@ -2795,11 +2795,7 @@ static int soc_get_playback_capture(struct snd_soc_pcm_runtime *rtd, > > SNDRV_PCM_STREAM_CAPTURE : SNDRV_PCM_STREAM_PLAYBACK; > > > > for_each_rtd_codec_dais(rtd, i, codec_dai) { > > - if (dai_link->num_cpus == 1) { > > - cpu_dai = asoc_rtd_to_cpu(rtd, 0); > > - } else if (dai_link->num_cpus == dai_link->num_codecs) { > > - cpu_dai = asoc_rtd_to_cpu(rtd, i); > > - } > > + cpu_dai = asoc_rtd_to_cpu(rtd, i); > > Grr > I noticed that this patch is also wrong. > It doesn't care CPU:Codec = 1:N case. > Need v4 patch The playable/capturable calculation are similar operation, thus I had been thinking that it is possible to merge. But there are many patterns and has difference, moreover complex (therefor we noticed that lack of DPCM BE Codec check, but not sure it is lack or intentional). It seems that my posted patch-set has a high possibility to contain some new bugs which is difficult to notice. I'm still thinking that we can merge it and have more simple and understandable code, but I'm starting to think that it should more caution. So, I will post first few small cleanup patches only instead of v4 patch-set for this time. Thank you for your help !! Best regards --- Kuninori Morimoto