On Thu, Mar 11, 2021 at 04:43:20PM +0100, Michael Walle wrote: > This could be a last resort, yes. But I'd rather see a flag which > indicates whether the simple-audio-card should control the (first) > clock of the codec or not. Because until now, this wasn't the case. > And I don't know if this was an oversight or on purpose. Kuninori would > need to comment on that. And with the "we change mclk by default", we > break codecs with automatic sysclk generation. It shouldn't break anything so long as the clock ends up correct via some path. Where there's multiple options we can also try going through them in some order, preferring the clock in the CODEC would probably make sense from both a compatibility and quality point of view. > > > And its fetching just the first clock, doesn't it? What happens if a > > > codec has two clock inputs? > > Yes, it would have been more descriptive if it were specifically > > looking for clock "mclk". I think the original assumption was codec > > takes one input clock (MCLK) and uses it for sysclk. > Yeah, I've just noticed that the clk_get_rate() also only works > for the first clock of the codec. simple-audio-card isn't really intended to work with complex devices, it's very much only for the simplest of use cases.
Attachment:
signature.asc
Description: PGP signature
