PPS kernel issue on Jetson Xavier AGX (L4T 34.1.1)

I wanted to put this somewhere on the internet to save others the hours of hassle that I spent on this problem.

There is an issue with PPS in the Linux Kernel version 5.10.65-tegra that I am using. The link below explains the issue better than I can, but essentially the PPS setup code overrides an error with EINVAL unnecessarily.

If booting from an NVME drive and flashing using the l4t_initrd_flash.sh script, a GPIO PPS device will never be initialized despite proper kernel and device tree configuration. My theory for why this happens is that the NVME boot process takes longer than booting from EMMC, and thus the GPIO device is not ready before the PPS kernel code tries to add a PPS GPIO pin. The bad kernel code overrides the error with EINVAL and makes the system abandon PPS altogether. By making the change in the kernel source code from the link above, the proper error code is thrown and the call to add the GPIO pin is retried later.

This requires recompiling the kernel, which is its own can of worms.

The following output from dmesg supports this theory:

[    0.565300] pps_core: LinuxPPS API ver. 1 registered
[    0.565331] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    3.385005] pps_ldisc: PPS line discipline registered
[    3.389811] pps-gpio pps_gpio: failed to request PPS GPIO
[    7.192833] pps_core: source pps_gpio.-1 got cdev (246:0)
[    7.192850] pps pps0: new PPS source pps_gpio.-1
[    7.193192] pps pps0: Registered IRQ 276 as PPS source

hello mcguire.jacob,

may I double confirm the L4T release version you’re using.
since rel-32 is stick with k-4.9; it should be rel-35 code-line since you’re having k-5.10.

hello mcguire.jacob,

BTW,
please also refer to this thread, Topic 107409 for the steps to use GPIO as PPS interface.
thanks

I actually did get it working. I posted this thread for others awareness about how. Also you are right, I am using version 34.1.1, not 32.

hello mcguire.jacob,

we’ve also checking this issue internally.
we also have this (same as your modification) as simple workarounds for probing failed.

diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c
index e0de1df2ede0..f7dc1ad2c869 100644
--- a/drivers/pps/clients/pps-gpio.c
+++ b/drivers/pps/clients/pps-gpio.c
@@ -186,7 +186,7 @@ static int pps_gpio_probe(struct platform_device *pdev)
 	} else {
 		ret = pps_gpio_setup(pdev);
 		if (ret)
-			return -EINVAL;
+			return ret;
 	}

on the other hand,
if you compile the PPS-GPIO driver as a module which load after the kernel setup, it’ll also skip the failure.
it looks like the issue is pps-gpio driver request the GPIO before it’s ready.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.