We’re running the Jetson TX2 on a custom carrier board, with the possibility to attach up to 3 IMX267 sensors. This is working fine so far, except when plugging a USB somehow the probe function from my driver is called, see this dmesg log:
[ 592.131605] usb 2-1: new SuperSpeed USB device number 5 using tegra-xusb
[ 592.153156] usb 2-1: New USB device found, idVendor=0951, idProduct=1666
[ 592.153180] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 592.153197] usb 2-1: Product: DataTraveler 3.0
[ 592.153211] usb 2-1: Manufacturer: Kingston
[ 592.153225] usb 2-1: SerialNumber: AC220B280B7BE271C91C0977
[ 592.157336] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 592.158530] scsi host2: usb-storage 2-1:1.0
[ 592.161505] imx267_probe: called
[ 592.161509] imx267_probe: module version: 0.4
[ 592.161515] imx267 30-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 592.161559] imx267_parse_dt: called
[ 592.161584] imx267 30-001a: reset-gpios not found -517
[ 592.166900] imx267 30-001a: tegra camera driver registration failed
[ 592.173522] imx267_probe: called
[ 592.173525] imx267_probe: module version: 0.4
[ 592.173529] imx267 32-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 592.173569] imx267_parse_dt: called
[ 592.173617] imx267 32-001a: reset-gpios not found -517
[ 592.178895] imx267 32-001a: tegra camera driver registration failed
[ 592.185406] imx267_probe: called
[ 592.185409] imx267_probe: module version: 0.4
[ 592.185414] imx267 34-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 592.185454] imx267_parse_dt: called
[ 592.185509] imx267 34-001a: reset-gpios not found -517
[ 592.190784] imx267 34-001a: tegra camera driver registration failed
[ 593.170182] scsi 2:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[ 593.181640] sd 2:0:0:0: [sda] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
[ 593.181937] imx267_probe: called
[ 593.181941] imx267_probe: module version: 0.4
[ 593.181941] imx267 30-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 593.181981] imx267_parse_dt: called
[ 593.182005] imx267 30-001a: reset-gpios not found -517
[ 593.182007] imx267 30-001a: tegra camera driver registration failed
[ 593.182097] imx267_probe: called
[ 593.182100] imx267_probe: module version: 0.4
[ 593.182101] imx267 32-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 593.182125] imx267_parse_dt: called
[ 593.182139] imx267 32-001a: reset-gpios not found -517
[ 593.182140] imx267 32-001a: tegra camera driver registration failed
[ 593.182200] imx267_probe: called
[ 593.182203] imx267_probe: module version: 0.4
[ 593.182203] imx267 34-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[ 593.182226] imx267_parse_dt: called
[ 593.182239] imx267 34-001a: reset-gpios not found -517
[ 593.182240] imx267 34-001a: tegra camera driver registration failed
[ 593.224989] sd 2:0:0:0: [sda] Write Protect is off
[ 593.229870] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[ 593.231301] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 593.344358] sda: sda1
[ 593.348590] sd 2:0:0:0: [sda] Attached SCSI removable disk
Because no sensors boards are attached during this test, it will result in a fail. However, why is this function even being called? How can I avoid this? It’s also excessively being called when the TX2 is booting…
FYI; the sensor boards are all attached through a I2C switcher, so the chain is like this:
TX2 → tca9548 i2c switcher → imx267 sensor + tca6408 io extender (io extender also contains reset-gpios)
The I2C switch regulator is defined as follows in my device tree:
tca9548_71: tca9548@71 {
status = "okay";
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
vcc-supply = <&battery_reg>;
/*skip_mux_detect;*/ /* Falco: disabling this forces the mux as available even when its not there */
force_bus_start = <CAMERA_I2C_MUX_BUS(0)>;
i2c@0 {
reg = <0>;
i2c-mux,deselect-on-exit;
#address-cells = <1>;
#size-cells = <0>;
};
....
The vcc-supply is &battery_reg, which is indeed the same as the USB vcc-supplies because we don’t have seperate vbus enables, could that be the issue? Should I make an other dummy regulator?
Edit: I tried replacing it by adding a dummy regulator in tegra186-cvb-prod-p2597-b00-p3310-1000-a00-00.dtsi as follows:
there’re several dtsi files included to generate device tree file;
suggest you should also disassembler the compiled dtb file into txt file for examination.
i.e. $ dtc -I dtb -O dts -o results.txt tegra.dtb
GPIO drivers can be on I2C, SPI, etc. buses and aren’t always accessible when the driver that needs them goes to initialize. In that case, many drivers will return -EPROBE_DEFER(-517) as an error code (see errno.h). This is a signal to the bus driver that the device did not have a hard failure and that it should retry again later. During initialization this could be based on some sort of timer or as other drivers get initialized. The kernel doesn’t know what will make the driver succeed so it will retry numerous times. After initialization this re-probe operation is repeated for those DEFERRED devices that never got initialized properly, whenever the system changes. So if you connect a USB device to your system it changes it and the kernel thinks, “maybe now that driver will be able to find the hardware resource it was looking for” and it calls the probe operation again.
I searched the kernel sources, but I couldn’t find anything for the imx267. If you have the source, look for where it is trying to get the “reset-gpios” property from the DT. In the driver somewhere it will be trying to get it or use it and when it fails it is returning a -EPROBE_DEFER. At that point you can return a different error code and the kernel subsystem will stop retrying that device.
The short answer is: it is doing exactly what the driver told it to do “Driver requests probe retry” later.
Thank you so much for all this information! There are no kernel sources for imx267, we had to make a driver ourselves. But we copied it from the examples from Nvidia, who indeed return -EPROBE_DEFER upon no reset-gpios detection.
After googling I found that this -EPROBE_DEFER could be useful if there are issues with trying to probe your device too early at boot while other drivers/probes haven’t been done that are necessary for your own probe, but if I look into the dmesg log it always works on first try if a camera is connected.
So, for our use case, there is no need to probe over and over again. So I changed this portion of our driver so it returns it’s default value NULL instead of -EPROBE_DEFER
struct camera_common_pdata *ret = NULL;
...
gpio = of_get_named_gpio(np, "reset-gpios", 0);
if (gpio < 0) {
/*if (gpio == -EPROBE_DEFER) //Falco: Commented out to avoid spurious probing
ret = ERR_PTR(-EPROBE_DEFER);*/
dev_err(dev, "reset-gpios not found %d\n", gpio);
board_priv_pdata->reset_gpio = 0;
goto error;
} else
printk("%s of_get_named_gpio (reset-gpios) found\n", __FUNCTION__);
...
error:
devm_kfree(dev, board_priv_pdata);
return ret;
Unfortunately I’m still getting spurious probes when plugging an USB device…
[18932.218330] tegra-xusb 3530000.xhci: exiting ELPG
[18932.230190] tegra-xusb 3530000.xhci: Firmware timestamp: 2018-12-26 10:30:04 UTC, Version: 55.12 release
[18932.231859] tegra-xusb 3530000.xhci: exiting ELPG done
[18932.535587] usb 1-2: new high-speed USB device number 2 using tegra-xusb
[18932.560173] usb 1-2: New USB device found, idVendor=0951, idProduct=1666
[18932.560211] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[18932.560233] usb 1-2: Product: DataTraveler 3.0
[18932.560251] usb 1-2: Manufacturer: Kingston
[18932.560268] usb 1-2: SerialNumber: AC220B280C8CE271D9206585
[18932.569410] usb-storage 1-2:1.0: USB Mass Storage device detected
[18932.573514] scsi host2: usb-storage 1-2:1.0
[18932.576027] imx267_probe: called
[18932.576030] imx267_probe: module version: 0.4
[18932.576035] imx267 32-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[18932.576075] imx267_parse_dt: called
[18932.576104] imx267 32-001a: reset-gpios not found -517
[18932.581402] imx267 32-001a: tegra camera driver registration failed
[18932.587832] imx267_probe: called
[18932.587834] imx267_probe: module version: 0.4
[18932.587837] imx267 34-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[18932.587881] imx267_parse_dt: called
[18932.587911] imx267 34-001a: reset-gpios not found -517
[18932.593111] imx267 34-001a: tegra camera driver registration failed
[18933.581657] scsi 2:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[18933.598685] sd 2:0:0:0: [sda] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
[18933.600421] imx267_probe: called
[18933.600427] imx267_probe: module version: 0.4
[18933.600427] imx267 32-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[18933.600467] imx267_parse_dt: called
[18933.600493] imx267 32-001a: reset-gpios not found -517
[18933.600495] imx267 32-001a: tegra camera driver registration failed
[18933.600570] imx267_probe: called
[18933.600573] imx267_probe: module version: 0.4
[18933.600573] imx267 34-001a: [IMX267]: probing v4l2 sensor at addr 0x1a.
[18933.600597] imx267_parse_dt: called
[18933.600611] imx267 34-001a: reset-gpios not found -517
[18933.600613] imx267 34-001a: tegra camera driver registration failed
[18933.629513] sd 2:0:0:0: [sda] Write Protect is off
[18933.634514] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[18933.634801] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[18933.697992] sda: sda1
[18933.699421] sd 2:0:0:0: [sda] Attached SCSI removable disk
Are you using a built-in driver or a kernel module?
Just to double check that your running the new code that you are hoping to verify, add a print at the beginning the probe that is new. This verifies that you are in fact running the new driver code.
I still see -517 in your log so I suspecting either you did not update the kernel module on your file system (if you are using a kernel module), or you are still running your old kernel. That could just be printed by your call to of_get_named_gpio() and may not be what your drivers probe is actually returning.
Add a few more prints so you can see where it is returning from and print the value it is returning on failure. Make sure you are capturing your log from dmesg and not from what you see on the serial console. dmesg will capture non-error and non-warning messages which can often be helpful/essential in debugging. You can’t go wrong with too many prints at this point as you are just trying to figure things out.
I’m using it as a module, rerunning my steps I saw I forgot something and thus the old driver was compiled again… Thanks for making me check again ;) I’ve also edited the dev_err to be able to verify the new driver is being used. The -517 being printed is correct, because it prints the result of_get_named_gpio() which is the source of the -EPROBE_DEFER as you can see in the commented out if statement.
Anyway, now using the proper, new driver it gives the following result when plugging an USB stick:
[ 365.788709] tegra-xusb 3530000.xhci: exiting ELPG
[ 365.801177] tegra-xusb 3530000.xhci: Firmware timestamp: 2018-12-26 10:30:04 UTC, Version: 55.12 release
[ 365.802681] tegra-xusb 3530000.xhci: exiting ELPG done
[ 366.027949] usb 1-2: new high-speed USB device number 3 using tegra-xusb
[ 366.052538] usb 1-2: New USB device found, idVendor=0951, idProduct=1666
[ 366.052573] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 366.052596] usb 1-2: Product: DataTraveler 3.0
[ 366.052609] usb 1-2: Manufacturer: Kingston
[ 366.052626] usb 1-2: SerialNumber: AC220B280C8CE271D9206585
[ 366.063479] usb-storage 1-2:1.0: USB Mass Storage device detected
[ 366.065726] scsi host2: usb-storage 1-2:1.0
[ 367.101992] scsi 2:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[ 367.120861] sd 2:0:0:0: [sda] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
[ 367.128761] sd 2:0:0:0: [sda] Write Protect is off
[ 367.133604] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[ 367.133884] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 367.196960] sda: sda1
[ 367.199390] sd 2:0:0:0: [sda] Attached SCSI removable disk
Thank you very much JDSchroeder! This solved the spurious probes. However, now I’m running against the problem why probably the defer was added in the first place, the imx driver probe function runs before the probe function of the gpio’s it’s trying to use… Oh well, that’s outside the scope of this forum topic, thanks again though!