On 2019-01-15 12:11, Dimitris Papavasiliou wrote: > On Tue, Jan 15, 2019 at 10:06 AM Peter Rosin <peda@xxxxxxxxxx> wrote: >> ...and when double-checking that, this dai op is only ever called from >> snd_soc_dai_set_bclk_ratio, and that function is in turn not called from >> anywhere AFAICT. What's the point of this dai op anyway? Or, what am I >> missing? > > Well, my use for this, would be to allow the machine driver to call > snd_soc_dai_set_bclk_ratio, in order to explicitly set the frame > width. This would allow it to use 32-bit frames for 24-bit data and > avoid the fractional dividers that would otherwise result. Right now, > the machine driver (which lives in the Raspberry Pi kernel tree) uses > a workaround for this, that relies on a patch made to the CODEC driver > to half-support TDM slots, which hasn't be pushed upstream, and > wouldn't be accepted if it had, since it's essentially a hack. You > can find more details here: > > http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143507.html > > What the intended use for the snd_soc_dai_set_bclk_ratio is, I'm not > so clear about, hence this RFC. I did some digging. The dai op was added in 3.13 (without users), then one user appeared in 3.19 (sound/soc/intel/boards/bytcr_rt5640.c) and another (presumably copy-pasted) in 4.5 (sound/soc/intel/boards/bytcr_rt5651.c). Both these users are suspect since neither the rt5640 nor the rt5651 codec have ever sported a set_bclk_ratio dai op, and presumably the boards have the named codecs on them. But what do I know... The user added in 3.19 was removed for 4.9 and the other for 4.17, so that's why there are no upstream users at the moment. Cheers, Peter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
