On Mon, Aug 28, 2023 at 12:50:45AM +0300, Marian Postevca wrote:
Mark Brown broonie@kernel.org writes:
machine with this MCLK rather than that's based on the spec. I would instead suggest applying the MCLK divider in any case where we can do so and still generate suitable clocking for the rest of the system, or at least hit 256fs (the datasheet quotes 256/384fs on the front page which suggests it's targetting 256fs, that'd be a fairly normal number, and there's mention of 12/24MHz USB clocks being directly usable). Doing this should either make no odds or result in better performance.
Not 100% sure what checks should be done for a MCLK to determine if it generates suitable clocking. Would something along this patch make sense?
In general a MCLK that allows you to configure the dividers in the CODEC appropriately for use. So long as it works your change looks fine I think modulo.
- do {
/* Validate supported sample rates that are autodetected from MCLK */for (i = 0; i < NR_SUPPORTED_MCLK_LRCK_RATIOS; i++) {const unsigned int ratio = supported_mclk_lrck_ratios[i];if (clk % ratio != 0)continue;if (clk / ratio == params_rate(params))break;}
Use ARRAY_SIZE()