Setting NVHS_PLL clock frequency

Hi Folks -

I am looking to adjust the PLL_NVHS frequency but I am having no luck. I have followed the advice in the Clock section of the Linux Developers Guide r32.4.3 and tried to manually override the clock frequency with:

echo 1 > /sys/kernel/debug/bpmp/debug/clk/pll_nvhs/mrq_rate_locked 
echo 1 > /sys/kernel/debug/bpmp/debug/clk/pll_nvhs/state
echo 70000000 > /sys/kernel/debug/bpmp/debug/clk/pll_nvhs/rate

But the magic spell has no effect. I do not find any other location where this clock rate may be set.

Any ideas on how the PLL_NVHS rate can be configured?

Thanks!

For what purpose need to set this clock?

We are integrating a sensor for testing that wants a clock at a different frequency. The clock on the PCIE x16 header pins A13 and A14 would be convenient. We can get a clock out at 72 MHz which appears to be tied to the NVHS_PLL (though the documentation is unclear). It would be great if we can change that frequency.

I’m a bit confused by this statement. Are you saying that you are already able to get 72 Mhz differential clock on A13 and A14? (or) is it just that you want to get this clock on A13 and A14?
BTW, Since this is a PCIe slot, the standard 100 Mhz PCIe reference clock is supplied on these pins. Is this slot being repurposed in your use case? (and hence the requirement to receive a different frequency clock?)

Also, which bus the sensor is sitting on? (Is it PCIe/I2C/SPI or some thing else?)

@vidyas, thank you very much for responding to my post. I will elaborate and hopefully we can clear up the confusion together.

  1. Our hope is to use the PCIe x16 expansion connector for interfacing with our sensor. We would like to use the SPI2 port shown as A5-A8 though we haven’t yet tried to interface with it. Our ultimate goal is to get an SLVS sensor running; this clock manipulation is just one piece of that effort. We have been unable to get the imx204.c code to do anything interesting. If there is an example of an SLVS code running, we’d be happy to start there.
  2. To get a clock out of A13/A14, we configured the device tree to set REFCLK_SEL low and enabled pcie@141a0000, A small modification to pcie-tegra.c keeps the “pcie system” awake even though there is no link.
  3. With this configuration, the Xavier drives A13/A14 at 72 MHz. I realize this is not the standard 100MHz PCIe clock – I don’t know why this clock is at this frequency.
  4. Looking through bpmp/debug/clk/clk-tree, NVHS_PLL is the only clock at this frequency, and when the clock is disabled (echo 0 > nvhs_pll/state) the signal on A13/A14 disappears.
  5. The slvs-ec device is enabled in the device-tree. This may confuse the answers. It was enabled as part of the efforts to get a clock out based on the comments in section 7.2.3.3.5. That section also led us to suspect nvhs_pll as the 72 MHz source. I have disabled slvs-ec in device tree but will not be able to check the A13/A14 output until Monday.

Thanks for following up - even writing down this description suggested a few more things to try. Your advice is very welcome.

Hi,
Unless you are trying a custom base board, the AGX’s default base board has REFCLK_SEL configured correctly and to keep the REFCLK flowing into the slot even with no PCIe device connected/no PCIe link up, you can just remove the “nvidia,enable-power-down;” entry from the pcie@141a0000 node.
I’m also surprised to see that you get 72MHz and not 100MHz. Could you please try the above method to get the REFCLK? Also you mentioned that you had made some changes in pcie-tegra.c file. would you mind sharing those changes? Certainly 72MHz is not the expected value there.

For the SPI you may need to check the pinmux as below link.

We are using IMX421 with SLVS-EC interface, and it has issues too. Still debugging.

Progress! We had been flashing the board with the slvs target board: “./flash.sh jetson-xavier-slvs-ec mmcblk0p1”. This results in 72.0 MHz at the output. If we flash the board with the standard command, “./flash.sh jetson-xavier mmcblk0p1” we get the 100 MHz output.

This is a result of parallel efforts to get SLVS functionality working.

So this is good news! Now we can get PLL_NVHS to be two separate frequencies: 100 MHz and 72 MHz, depending on the target board. In neither mode can we adjust the fixed PLL_NVHS frequency. Where can we change this frequency?


@vidyas You are correct, to keep the PCIe port alive, we removed nvidia,enable-power-down from the device tree node. We made no functional changes to pcie-tegra.c, only changes to log info and confirm the functionality of the “nvidia,enable-power-down” entry.

However, we do need to enable the pex-refclk-sel-low node (and disable the high node) to get the clock through the external mux.

Further debugging: a Bootloader Update Package with a jetson-xavier target and installed with nv_update_engine gives a 100 MHz NVHS_PLL clock output. A BUP with jetson-xavier-slvs-ec target gives 72 MHz. So the clock configuration is not with the device tree or the undocumented “BPMP clock API” – it lies with the bootloader configuration.

After looking at the jetson-xavier-slvs-ec target for a while and trying to figure out what it is doing the ODMDATA=0x9291000 flag in “jetson-xavier-slvs-ec.conf” changes the configuration from 100 MHz to 72 MHz.

I found ODMDATA information in here: https://developer.download.nvidia.com/embedded/L4T/r32_Release_v1.0/Docs/Tegra_Linux_Driver_Package_AGX_Xavier_Adaptation_Guide.pdf. In particular, a look at /proc/device-tree/chosen/plugin-manager/odm-data. shows that the slvs-ec target configures “enable-nvhs-uphy-slvs” and “enable-pcie-c5-endpoint”. Poking around through cboot sources reveals the bit masks for the ODMDATA flags, which is very welcome. However, I still don’t find anywhere that the NVHS_PLL clock frequency is set.