do i have to use an available freq?

[xrstokes]

/sys/devices/57000000.gpu/devfreq/57000000.gpu/available_frequencies
76800000 153600000 230400000 307200000 384000000 460800000 537600000 614400000 691200000 768000000 844800000 921600000 998400000

I don't seem to have any errors at 998.4 but you say in the post 950. if i select 921.6 i'm not over stock freq though. Can i add another in the middle?

Thanks so much for your work and effort that went into this.

[Qengineering]

It's all a matter of trail and error. The max frequency will work most of the time.
However, when running some deep learning model with 100% CPU and 100% GPU (CUDA) we experienced some issues at 998.4 MHz. Hence the 950 in the post.
No need to put a new value in the middle. You can give whatever frequencies you like echo 950000000 > /sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq in the file overclock.sh.

[xrstokes]

when i tried to set it to 950 it seems to jump to 998. same with cpu. it jumps to the closest available. in my case 1912Mhz

Package: nvidia-jetpack
Version: 4.5-b129
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-cuda (= 4.5-b129), nvidia-opencv (= 4.5-b129), nvidia-cudnn8 (= 4.5-b129), nvidia-tensorrt (= 4.5-b129), nvidia-visionworks (= 4.5-b129), nvidia-container (= 4.5-b129), nvidia-vpi (= 4.5-b129), nvidia-l4t-jetson-multimedia-api (>> 32.5-0), nvidia-l4t-jetson-multimedia-api (<< 32.6-0)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_4.5-b129_arm64.deb
Size: 29358
SHA256: 9ee354a66d932a3fbb244c926f333143a845c627c6981d108e01df2958ac462c
SHA1: 0e07f27c6fb9e34a70c69ae1150d1e578e938089
MD5sum: a551bbc8ff653c8983ce1804082bbcab
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

[Qengineering]

OK, seems NVIDIA has changed the governor since i wrote the post.
Leaves you with two options, both I didn't test.

1. Alter the 998400000 to a lower number.
2. Place a extra value in the sequence.

Both methods can cause the PLL to malfunction.
Or just accept the 921 MHz, and drop the extra 3%