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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
