Re: [PATCH RFC 2/3] ASoC: hdmi-codec: add support for bclk_ratio

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1678 bytes --]

On Mon, Feb 25, 2019 at 03:45:44PM +0200, Jyri Sarha wrote:
> On 22/02/2019 23:27, Russell King wrote:

> > +	/*
> > +	 * If the .set_bclk_ratio() has not been called, default it
> > +	 * using the sample width for compatibility for TDA998x.
> > +	 * Rather than changing this, drivers should arrange to make
> > +	 * an appropriate call to snd_soc_dai_set_bclk_ratio().
> > +	 */
> > +	if (fmt.bclk_ratio == 0) {
> > +		switch (hp.sample_width) {
> > +		case 16:
> > +			fmt.bclk_ratio = 32;
> > +			break;
> > +		case 18:
> > +		case 20:
> > +		case 24:
> > +			fmt.bclk_ratio = 48;
> > +			break;

> AFAIK, this is not the usual choice for 18- or 20-bit samples. Usually,
> the bclk_ratio is set to the exact frame length required by the sample
> width without any padding. That is at least the case with
> tlv320aic3x-driver and 20-bit sample width.

So, this is true.  On the other hand like Russell says further down the
thread it's preserving the existing behaviour so it would be surprising
if it actually broke anything and it will help systems that explicitly
set the ratio so I don't think we should let perfect be the enemy of
good here.

As Russell outlined there's quite a bit of hopeful assumption in how
ASoC handles the mapping of memory formats onto wire formats which works
almost all the time but not always and definitely not through robust
design, that should be a lot easier to address once the component
conversion has been done as we'll actually have all the links in the
system directly visible rather than bundled up together and implied as
they are currently.  Sadly that's a lot of work with not many people
working on it so progress is super slow.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]