hello mhtechdev,
that’s due to GPIO allocation range changes since kernel-5.10.
you may see-also developer guide, To check a GPIO number for reference, thanks
Ok, but if I understand correctly both setups should be correct, since the old one shows GPIO13, and the new one shows PN.01 which both refer to the same physical pin (33 on the 40pin header)?
What else could be the reason that the pps signal doesn´t show on the JP5.0.2 NX?
I am using the same physical setup, a DevKit with pps connected to pin 33, and it works on JP4.4.
dmesg | grep pps (after using insmod to add pps kernel module) now returns:
[ 0.406432] pps_core: LinuxPPS API ver. 1 registered
[ 0.406451] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[ 3.163099] pps pps0: new PPS source ktimer
[ 3.163241] pps pps0: ktimer PPS source registered
[ 3.165348] pps_ldisc: PPS line discipline registered
[ 1036.296090] pps pps1: new PPS source pps.-1
[ 1036.296286] pps pps1: Registered IRQ 272 as PPS source
So it looks like it is registered correctly, but it never sees a change on the pps gpio.
/sys/class/pps/pps1/assert is always 0.000000000#0, and ppstest /dev/pps1 times out
hello mhtechdev,
could you please try adding below in kernel dtb,
for example,
pps {
gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>;
compatible = “pps-gpio”;
assert-falling-edge;
status = “okay”;
};
Hi JerryChang,
I have tried adding it both to
hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-0000-p3509-0000.dts
and
/hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tagra194-soc-base.dtsi
but with the same effect. /dev/pps1 shows up, but does not register gpio changes.
hello mhtechdev,
you meant that you’re able to see sysnode, /sys/class/pps/pps1/.
but, there’s nothing happened whenever interrupt occurs, by checking… $ cat /sys/class/pps/pps1/assert
according to device tree code snippets,
pps {
...
assert-falling-edge;
it’s assert on the falling-edge of signal, if you want events to generate on rising-edge of signal, please remove the property for confirmation.
Hello JerryChang,
I have a continuous PPS signal attached, so including both rising and falling edges, and no events are generated at all.
I have tried both with and without assert-falling-edge, and none of the two cases work.
this is a generic linux driver; please make sure that the driver probe is happening and please following the linux documentation.
I managed to get one step further (or one step back, I´m not fully sure).
I realised that when decompiling the kernel and adding:
pps { compatible = "pps-gpio"; gpios = <0xffffffff 0x69 0x01>; status = "okay"; };
and then recompiling again, it does not add /dev/pps1, but the following is printed in dmesg:
[ 0.397145] pps_core: LinuxPPS API ver. 1 registered
[ 0.397157] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[ 2.979984] pps pps0: new PPS source ktimer
[ 2.980137] pps pps0: ktimer PPS source registered
[ 2.983027] pps_ldisc: PPS line discipline registered
[ 92.928373] OF: /pps: could not find phandle
[ 92.928515] pps-gpio pps: failed to request PPS GPIO
[ 92.928671] pps-gpio: probe of pps failed with error -22
I have seen other similar threads where this was suggested to be caused by too early initialization of the pps-driver, but I have already added CONFIG_PPS_CLIENT_GPIO=m.
I tried to add the suggested fix of replacing the return -EINVAL; with ret in
static int pps_gpio_probe(struct platform_device *pdev)
{
…
} else {
ret = pps_gpio_setup(pdev);
if (ret)
return ret;
but with no effect.
hello mhtechdev,
you may add the flag CONFIG_DYNAMIC_DEBUG into tegra_defconfig and rebuild the kernel.
please see-also Topic 224203 to enable dynamic debug flag of pps driver and debug further.
Hello JerryChang,
I have tried to enable CONFIG_DYNAMIC_DEBUG as well as adding the debug prints mentioned in the linked topic (even though it doesn´t seem like it gets to the FETCH, as the GPIO setup fails).
Did:
# cd /sys/kernel/debug/dynamic_debug/
# echo file pps.c +p > control
and then ran insmod pps-gpio.ko, but the output from dmesg | grep pps is the same.
Also now cat /sys/kernel/debug/gpio doesn´t show the pps GPIO anymore
hello mhtechdev,
are you kept seeing this failure? is yes, that’s due to your device tree implementation, please review you’re define the pin correctly.
Hi JerryChang,
Yes, the issue is the same. And I can´t find the problem with the GPIO definition.
I am still using
gpios = <0xffffffff 0x69 0x01>;
which is also what
gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>;
is compiled into as far as I can see.
I also don´t really understand why the old procedure of just creating a dtbo and applying it with jetson-io doesn´t work…
hello mhtechdev,
it looks like some issues for using GPIO marco, please try using gpio number directly.
for example, it’s gpio-419 for PN.01.
gpios = <&tegra_main_gpio 419 GPIO_ACTIVE_LOW>;
Using 419 didn´t work at all for some reason, with pps not showing up in /sys/kernel/debug/gpio at all.
But I managed to get to the following now:
[ 334.111412] pps pps1: PPS_GETPARAMS
[ 334.111447] pps pps1: PPS_GETCAP
[ 334.111458] pps pps1: PPS_GETPARAMS
[ 334.111469] pps pps1: PPS_SETPARAMS
[ 334.111477] pps pps1: time format unspecified (11)
[ 334.111607] pps pps1: PPS_FETCH
[ 334.111617] pps pps1: timeout 3.000000000
[ 337.115582] pps_core: Error in cdev_pps_fetch: ETIMEDOUT
[ 337.115593] pps_core: pps Error in PPS_FETCH: -110
[ 337.116061] pps pps1: PPS_FETCH
[ 337.116071] pps pps1: timeout 3.000000000
[ 340.187534] pps_core: Error in cdev_pps_fetch: ETIMEDOUT
[ 340.187544] pps_core: pps Error in PPS_FETCH: -110
[ 340.187988] pps pps1: PPS_FETCH
[ 340.187998] pps pps1: timeout 3.000000000
[ 340.195238] pps_core: Error in cdev_pps_fetch: -ERESTARTSYS
[ 340.195248] pps pps1: pending signal caught
[ 340.195408] pps_core: pps Error in PPS_FETCH: -4
with the following debug prints in pps.c:
case PPS_FETCH: {
…
err = copy_from_user(&fdata, uarg, sizeof(struct pps_fdata));
if (err) {
pr_err(“-EFAULT in PPS_FETCH pps\n”);
return -EFAULT;
}
err = pps_cdev_pps_fetch(pps, &fdata);
if (err) {
pr_err(“pps Error in PPS_FETCH: %d\n”, err);
return err;
}
hello mhtechdev,
if there was any error the IOCTL sequence/call would have failed…
you may check if interrupt count is increasing, please check the irq interrupt of pps pin, the interrupt counter should increase by one for every second.
Yes, the interrupt count for pps1 in /proc/interrupts counts up, and stops increasing when I disconnect the physical PPS wire. So the GPIO config is fine I guess? Why doesn´t it get through to the PPS driver?
According to Using pps-gpio on Orin - #3 by JerryChang the issue is known and you are looking into it? I haven´t been able to get further, so any further help is appreciated.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.