On Tue, 21 Jan 2020 09:11:06 +0100, Kuninori Morimoto wrote: > > > Hi Takashi > > Thank you for feedback > > > Actually the question is whether we need snd_pcm_limit_hw_rates() call > > or not. The current code in soc_pcm_init_runtime_hw() assumes that > > each cpu and codec dais already set the proper rate_min and rate_max, > > and narrow the range accordingly. So basically the call there is > > superfluous. OTOH, in dpcm_fe_dai_startup(), the call overrides the > > existing rate_min/max setup as you mentioned, so it may be wrong. > > OK, it is same as my understanding. > I want to do (so far) is just cleanup. > I will fixup/cleanup it. > > I'm posting ALSA SoC cleanup patches to ML. > This fixup/cleanup will be added to my ALSA-SoC-cleanup-patch-queue Actually as Lars pointed out in another reply, the current code of soc_pcm_init_runtime_hw() is correct. It's a bit tricky but smartly handling the cases: when rate_min/max are to be overridden by rates bits, they are supposed to be zero, and min_not_zero() does the trick. Also, snd_pcm_rate_mask_intersect() sanitizes the bits when CONTINUOUS or KNOT is set, so the spurious rate bits won't be reflected in snd_pcm_limit_hw_rates(), too. But still the dpcm_fe_dai_startup() needs to be fixed as you mentioned. Though, I guess we need to fix not there but rather other places (e.g. dpcm_set_fe_runtime() itself). thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
