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

[Pierre-Louis Bossart]

On 3/8/19 3:13 PM, Mark Brown wrote:
> On Fri, Mar 08, 2019 at 02:49:48PM -0600, Pierre-Louis Bossart wrote:
>
>> I am not sure I fully understand the ask but wanted to point out that for
>> ASoC topology-based solutions the bclk rate is typically passed as a
>> parameter from userspace (w/ a request_firmware and topology parsing) and
> You mean for x86 systems :)  Well, big DSP really.  It's not really
> topology related.

I was referring to asoc.h and the following structure. For once it's not 
an Intel-specific hack, though the topology does need a lot of love to 
be hardened and extended.

struct snd_soc_tplg_hw_config {
     __le32 size;            /* in bytes of this structure */
     __le32 id;        /* unique ID - - used to match */
     __le32 fmt;        /* SND_SOC_DAI_FORMAT_ format value */
     __u8 clock_gated;    /* SND_SOC_TPLG_DAI_CLK_GATE_ value */
     __u8 invert_bclk;    /* 1 for inverted BCLK, 0 for normal */
     __u8 invert_fsync;    /* 1 for inverted frame clock, 0 for normal */
     __u8 bclk_master;    /* SND_SOC_TPLG_BCLK_ value */
     __u8 fsync_master;    /* SND_SOC_TPLG_FSYNC_ value */
     __u8 mclk_direction;    /* SND_SOC_TPLG_MCLK_ value */
     __le16 reserved;    /* for 32bit alignment */
     __le32 mclk_rate;    /* MCLK or SYSCLK freqency in Hz */
     __le32 bclk_rate;    /* BCLK frequency in Hz */
     __le32 fsync_rate;    /* frame clock in Hz */
     __le32 tdm_slots;    /* number of TDM slots in use */
     __le32 tdm_slot_width;    /* width in bits for each slot */
     __le32 tx_slots;    /* bit mask for active Tx slots */
     __le32 rx_slots;    /* bit mask for active Rx slots */
     __le32 tx_channels;    /* number of Tx channels */
     __le32 tx_chanmap[SND_SOC_TPLG_MAX_CHAN]; /* array of slot number */
     __le32 rx_channels;    /* number of Rx channels */
     __le32 rx_chanmap[SND_SOC_TPLG_MAX_CHAN]; /* array of slot number */
} __attribute__((packed));


>
>> might be forwarded over IPC to a DSP. On some Intel platforms which can't
>> support 32x fs that is typically how we represent a bclk ratio multiple of
>> 25. the kernel has no idea of the relationship between the representation of
>> the stream in memory and the final bit clock, only the DSP which programs
>> the hardware registers knows about the latter.
>> It's really quite typical that the DAI is programmed for a fixed
>> configuration and the DSP takes care of the conversions. The kernel only
>> deals with stream triggers and power management without know all the
>> internal details of the audio graph.
> I think this is more the issue with not having transitioned fully to
> components which we've talked about before I think - it's related but
> not quite the same thing.  In the big DSP case there's really two audio
> links that aren't really connected but we're currently trying to treat
> them as one since the code was designed for much smaller DSPs.

Yes, this notion of hw_params negotiation made me think about the 
constraints propagation that Lars talked about ~2 years ago, it's not as 
simple as a helper library I am afraid.

This discussion on bclk ratio makes a lot of sense. Some codecs have 
undocumented restrictions, e.g PCM512x or some Maxim amps, and it's not 
uncommon to come up with a configuration mismatch that take time to 
debug. If at least we could have an error thrown it'd be a good thing.