Greetings!
We're having issues using the PPS driver with GPIOs on the latest 5.4 kernel.
The following diff shows the changes to the device tree:
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-apalis.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-apalis.dtsi
2index d66e02a..916dc0c 100644
3--- a/arch/arm64/boot/dts/freescale/imx8qxp-apalis.dtsi
4+++ b/arch/arm64/boot/dts/freescale/imx8qxp-apalis.dtsi
5@@ -86,6 +86,15 @@
6 };
7 };
8
9+ gps_pps {
10+ compatible = "pps-gpio";
11+ pinctrl-names = "default";
12+ pinctrl-0 = <&pinctrl_gpio4>;
13+ gpios = <&lsio_gpio3 24 GPIO_ACTIVE_HIGH>;
14+ status = "okay";
15+
16+ };
17+
18 imx8x_cm4: imx8x_cm4@0 {
19 compatible = "fsl,imx8qxp-cm4";
20 rsc-da = <0x90000000>;
21@@ -539,10 +548,11 @@
22 status = "okay";
23 };
24
25+
26 &iomuxc {
27 pinctrl-names = "default";
28 pinctrl-0 = <&pinctrl_dap1_gpios>,
29- <&pinctrl_gpio3>, <&pinctrl_gpio4>, <&pinctrl_gpio5>,
30+ <&pinctrl_gpio3>, <&pinctrl_gpio5>,
31 <&pinctrl_gpio6>, <&pinctrl_mmc1_gpios>,
32 <&pinctrl_qspi0a_gpios>, <&pinctrl_sata1_act>,
33 <&pinctrl_usbh_oc_n>, <&pinctrl_usbo1oc>,
Using a Toradex Apalis iMX8X for testing, we get the following errors on dmesg:
root@apalis-imx8x:~# dmesg | grep pps
[ 0.139681] pps_core: LinuxPPS API ver. 1 registered
[ 0.139696] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 1.788427] pps_ldisc: PPS line discipline registered
[ 1.793999] pps-gpio gps_pps: failed to request PPS GPIO
[ 1.799379] pps-gpio: probe of gps_pps failed with error -22
[ 2.401493] pps pps0: new PPS source ptp0
We verified that this GPIO is available and works flawlessly using libgpiod.
We also tried this on an i.MX 6ULL with the same kernel version (both from NXP and mainline) and it works there, so this might be an issue with the lsio_gpio driver on the i.MX 8 family, perhaps? We had another customer complaining about a similar issue using an i.MX 8M Mini.
Any tips?
Thanks!
There is no side effects.
gpio_mxc_init function run before imx_scu_driver_init.
The pm_domains for gpio is not ready before running mxc_gpio_probe, so gpio will be deferred probe.
pps_gpio_probe run before gpio defered probe, it can't find gpio device, so the driver probe failed.
There are two ways to resolve this issue
1. Build pps-gpio driver to ko module, insmod it after mount rootfs.
2. Apply below patch, let gpio driver init after scu driver.
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 1dfe513f8fcf..52b5799040b3 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -892,7 +892,7 @@ static int __init gpio_mxc_init(void)
return platform_driver_register(&mxc_gpio_driver);
}
-subsys_initcall(gpio_mxc_init);
+device_initcall(gpio_mxc_init);
MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
MODULE_DESCRIPTION("i.MX GPIO Driver");
Thanks shaojun_wang,
the patch does work for me.
Does this change have any other side-effects I should be aware of?
Thanks again,
Manuel
Here is proven bsp has no problem.
and porting is related to the hardware and it is your job to debug the issue and finish porting.
technically, it is only related to linux. not imx.
it is waste time to prove such a basic thing, gpio is using in the dts everywhere.
using gpio_hog to do the test
imx8qxp-mek-gpio-hog-demo.dts
#include "imx8qxp-mek.dts"
&lsio_gpio3 {
gpio_hog_demo {
gpio-hog;
gpios = <24 0>;
/* output-low;*/
output-high;
};
};
So, in your dts file, which PAD you used for gpio3,24?
This is the definition of gpio3,24:
pinctrl_gpio4: gpio4grp {
fsl,pins = < IMX8QXP_QSPI0B_SS1_B_LSIO_GPIO3_IO24 0x21 /* MXM3 7 */ >;
};
PAD is not related to GPIO. GPIO is not PAD/PIN. PIN/PAD is not GPIO.
GPIO is module like UART, i2c, SPI, ADC.
no PAD mux configuration, GPIO still can work. just can not have output outside the chip.
you may check the gpio request in the pps source code.
I checked this code and it looks fine. There are other drivers existing that use the same function to obtain a GPIO on i.MX8 which works fine.
Plus this driver works fine on other SoCs like i.MX6/i.MX7. Which is why we suspect some code from NXP (SCFW related?) to make it fail which also makes it hard to debug.
Best Regards,
Philippe
Can you please be a bit more specific? I've looked at the pps driver code and also compared to other kernel versions and did not see anything obvious...
I did not find any other references on the web stating that the pps driver is broken...
I was told that this might be a potential bug in the imx8x gpio driver...
Can someone from NXP please take a look at this, as this seems to be a driver issue and thus NXP expertise is needed.
Thank you.