[alsa-devel] [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'

[Takashi Sakamoto]

On Tue, Mar 05, 2019 at 09:23:46AM -0500, Sven Van Asbroeck wrote:
> 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.

In your case:

+---+            +-----+
|CPU| <- wire -> |CODEC|
|DAI|            | DAI |
+---+            +-----+

So that:

CPU-DAI = fsl_ssi
CODEC-DAI = tda998x
wire = I2S

In I2S:
 - SCK-line = serial clock
 - WS-line = word select
 - SD-line = serial data 

In general I2S communication:
 - 2 samples are transferred in a phase of WS

In my opinion:
 - 'the number of clocks per frame on the wire' (=you need)
   = the number of phases of SCK per phase of WS

In expectation of ALSA PCM interface for hardware for usual device:
 - half number of phases of SCK per phase of WC
   = physical_width of sample
   = bytes per sample
 - the number of phases of SCK per phase of WC
   = physical_width * channels (=2)
   = bytes per frame
 - the ratio between phases of SCK and phases of WC per second
   = rate

Here, usual device is expected to give FIFO for DMA and I2S bus,
synchronized to SCK without any conversion. CODED-DAI also has
FIFO to process signals.

In my opinion, if both of fsl_ssi and tda988x have enough constraints
and rules for runtime of PCM substream about the physical_width, channels
and rate, things look to work well. Perhaps, tda998x driver should have a
condition statement for its role of 'frame master' to add the constraints
and rules, to describe its quirk.

It's helpful to describe the 'unique'ness of tda998x hdmi codec for
the detail.


Regards

Takashi Sakamoto (not maintainer of this subsystem)