On 2019-01-15 12:11, Dimitris Papavasiliou wrote:
On Tue, Jan 15, 2019 at 10:06 AM Peter Rosin peda@axentia.se 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.ht...
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