Hi Takashi, On Mon, Mar 4, 2019 at 11:42 PM Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx> wrote: > > Anyway, when posting to change UAPI of Linux sound subsystem, it's > better to describe the reason fot new stuffs; what they're designed for, > and the reason to require them. Wnen posting in a result of series of > discussion done previously, it's better to add any reference to it. My apologies for not linking in previous discussions, I'll certainly make sure to link in the future. The original problem was that the fsl_ssi did not appear to work with the tda998x hdmi codec. This codec seems to be 'unique' in the sense that it needs to know the number of clocks per frame on the wire, i.e. the bclk_ratio, which no-one in alsa is providing or using at the moment. I first made the error of conflating the physical width and the bclk_ratio, and posted this patch - Russell King quickly pointed out my error: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/145916.html This then led to the following discussions: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145985 https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145947 Most of the discussion is about a mechanism to convey bclk_ratio from the frame master to the tda998x. We don't yet seem to have a consensus on how to do this best. My rfc patch was only intended to provoke discussion, and to allow people to experiment with a flawed solution that would allow the alsa core to negotiate bclk_ratio between components. The uapi change is a serious flaw. bclk_ratio negotiation should be invisible to userspace. But I cannot see a way to accomplish this. Sven _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
