I understand, but one GPCLK to output the audio intermediate clock would be just fine. IIUC it's RP1_CLK_GP0 for pll_audio, RP1_CLK_GP2 for pll_audio_sec, and RP1_CLK_GP4+RP1_CLK_GP5 for pll_audio_ter. Please is it possible to revert the exclusions of these clocks in GPCLK parents as introduced in https://github.com/raspberrypi/linux/co ... 930b84ac8c?GPCLKs can be parented from /most/ other clock sources (their primary intent was to observe other clocks in the chip for test/debug) but each instance only samples a subset of the total inputs.
Do I understand correctly that it would take just configuring the parent GPCLK0 in DT to be pll_audio (which that commit disallowed), and then letting the I2S driver set some fs multiple suitable for mclk for the clk_i2s=bclk parent (i.e. pll_audio)? That's what e.g. the Rockchip I2S setup/driver does (it has dedicated mclk_i2s I/O pins which are also parents of the bclk_i2s clocks).I've always found the clocks framework to be be annoyingly restrictive - hence the suggestion to statically configure things with DT. That would make switching between a 44.1khz/48khz base basically impossible, unless GPCLKs had some notifier that computed a required divisor not a target clock rate.
The output frequency on the GPCLK pin would be determined by the driver. My main issue is to learn if the HW would support such configuration (IIUC it does which is really good news).
Modding the driver is a different question, it can be custom-hacked by implementers who need it. Often it will require some I2C config for the codec (typically setting MCLK fs multiple for the given fs) but that's standard Alsa SoC driver implementation work.
Thanks for the info. We can expect the interested audio people will measure the output clk jitter precisely for various VCO freqs when DT config allows the MCLK output.VCO jitter is generally improved with a higher VCO, but noise on 3v3 usually dominates the ~120ps (6-sigma) that you get.
Statistics: Posted by phofman — Mon Jul 22, 2024 9:01 am
