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