why is a no-pll a requirement?phofman wrote: ↑Mon Aug 03, 2020 8:34 pm49.152MHz "osc" frequency would allow no-PLL straight integer-divider generation of I2S signal for 48kHz audio multiples out of the box as the "osc" is already one of the parent clocks for the PCM clock. I have tested that when samplerate is integer-divided from 54MHz (e.g. 46.875kHz), the I2S bitclock is generated from the osc clock, correctly and cleanly.
Thanks a lot for the key info. I will not touch it then.
I am looking at options to explore the existing HW at max. Apparently the way of crystal replacement is not a viable one. Good to learnIf you need jitter-free I2S clocks, then use an I2S codec that can drive the clock as a master from its own internal crystal/PLL.
The intention was to check if minimizing jitter by avoiding the PLL was possible.
Thanks a lot for the info about accessing the clock tree, very useful.PLLC looks like the best choice, its not involved in anything that critical (dram, displays) so it could be freely played with, once you re-calc the sd/uart divisors
according to my old pastebins it runs at 3ghz by default, with a /5 divisor for the peripheral channel
600mhz/12500 gives you a perfect 48khz, and i think the divisor is 24 bits wide, so that should work without even messing with the PLL!
Thanks, no problem with adding other PLLs, but:https://github.com/raspberrypi/linux/bl ... 1600-L1618 and the driver goes out of its way to deny access to pllc_per!
and we can do the same to get a perfect 48khz pcm clock
Code: Select all
Please is there any summary writeup of the available clocks and their "adjustability" for RPi4? And which file is the correct one to change PLLx frequency + PLLx_PER ratio on RPi4? Thanks a lot.It is recommended when overclocking to use the individual frequency settings (isp_freq, v3d_freq etc) rather than gpu_freq, as since it attempts to set core_freq (which cannot be changed on the Pi 4), it is not likely to have the desired effect.
Almost certainly the case. Clocks are a juggling nightmare in the firmware. A couple of years ago I was trying to get a DSI->HDMI bridge chip going, and getting the clocks right for that meant all sorts of pain elsewhere in the system - I think it killed composite or something. We gave up in the end. Just not enough clocks to go round, along with other issues.
Specifically it's PLLs that are expensive. They're the only type of clock source capable of generating arbitrary frequencies from a fixed reference and are big, power-hungry chunks of silicon that need separate supply voltages and for optimal performance need to be placed close to where they need to deliver their clocks.