nvcamera-daemon dt (device tree) documentation (for l4t 28.2)

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hi nvidia

where is the documentation describing what nvcamera-daemon needs from the device tree entries to work and which are the accepted values for each field ?

background : we have written a driver for a spi (not i2c) sensor, /dev/video0 is created. v4l2-compliance detects no error, but nvcamerasrc is unusable because nvcamera-daemon either crashes, either falls in an endless loop doing nothing (with different dt’s of course). We cannot continue to try to make that work without knowing which informations must be provided in the dt, and if nvcamera-daemon is able to work with spi (not i2c) sensors.

best regards

2

Have you check the sensor programing guide in the l4t document?

3

I have read many documents, but have not found what I asked for in comment #1. Which document (url) do you refer to ?

4

Check below link
https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2-ga

5

I see there an example with

devname = "imx185 30-001a";
proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/imx185_a@1a"

but no explanation of what this really is.

I have found by myself that the equivalent for a spi (not i2c) connected sensor would be

devname = "imx264 spi1.1";
proc-device-tree = "/proc/device-tree/spi@7000d600/imx264@1"

but, does nvcamera-daemon parse ‘devname’ or does it use it as a constant string ? Is a SPI connected sensor supported ? That documentation still contains mentions of i2c-related and obsolete fields with regards to l4t 28.2 kernel sources, but there is not a single occurrence of the word ‘SPI’.

6

daemon get the driver name from v4l2 command and compare the string to pair the sensor.

7

I have only one sensor, and the v4l2 command is

gst-launch-1.0 nvcamerasrc ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)I420, framerate=(fraction)60/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)I420' ! omxh264enc bitrate=8000000 ! 'video/x-h264, stream-format=(string)byte-stream' ! filesink location=test1.h264 -e

where does the “driver name from v4l2 command” come from ?

does daemon compare the string received from the v4l2 command to the full devname (“imx264 spi1.1”) or does it first parse the devname into “imx264” and “spi1.1”, or does it expect to find some i2c-only syntax in devname ?

8

What I means is daemon send IOCTL command to v4l2 device to get the device name. Like v4l2-ctl -D

9

strace-ing nvcamera-deamon I see the ioctl, then nvcamera-daemon terminates and crashes without any explanation. What does it try to do there ?

30680 openat(AT_FDCWD, "/dev/video0", O_RDWR) = 45
30680 ioctl(45, VIDIOC_QUERYCAP, {driver="tegra-video", card="vi-output, imx264", bus_info="platform:54080000.vi:0", version=4.4.38, capabilities=V4L2_CAP_VIDEO_CAPTURE|V4L2_CAP_STREAMING|V4L2_CAP_DEVICE_CAPS|0x200000, device_caps=V4L2_CAP_VIDEO_CAPTURE|V4L2_CAP_STREAMING|0x200000}) = 0
30680 close(45)                         = 0
30680 getdents64(44, [], 32768)         = 0
30680 close(44)                         = 0
30680 write(2, "(NvOdmDevice) Error ModuleNotPresent: V4L2Device not available (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function findDevice(), line 245)\n", 173) = 173
30680 write(2, "(NvOdmDevice) Error ModuleNotPresent:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function initialize(), line 55)\n", 162) = 162
30680 write(2, "(NvOdmDevice) Error ModuleNotPresent:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function initialize(), line 103)\n", 176) = 176
30680 write(2, "NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor", 66) = 66
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor", 75) = 75
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclStartPlatformDrivers: Failed to start module drivers", 57) = 57
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b28e0", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b2970", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b2a00", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b2730", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b27c0", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0x7f851b2850", 74) = 74
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclStateControllerOpen: Failed ImagerGUID 0. (error 0xA000E)", 62) = 62
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclStateControllerClose: Module imx264_rear_A6V24 closed", 58) = 58
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclOpen: PCL Open Failed. Error: 0xf\n", 39) = 39
30680 write(2, "NvPclClose: ++++++++++++++++++++++", 34) = 34
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclClose: ----------------------", 34) = 34
30680 write(2, "\n", 1)                 = 1
30680 write(2, "NvPclOpen: ----------------------", 33) = 33
30680 write(2, "\n", 1)                 = 1
30680 write(2, "SCF: Error BadParameter: Sensor could not be opened. (in src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 598)\n", 150) = 150
30680 write(2, "SCF: Error BadParameter:  (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 781)\n", 123) = 123
30680 write(2, "SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 276)\n", 109) = 109
30680 write(2, "SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 439)\n", 102) = 102
30680 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
10

From your log the devname should be like below
devname = “imx264”;

ioctl(45, VIDIOC_QUERYCAP, {driver="tegra-video", card="vi-output, imx264",
11

Shouldn’t we rather (planning for the future when we could have more than one imx264 sensor on the same board) ensure that the ioctl answers card=“vi-output, imx264 spi1.1” ?

I see that this seems to be built in tegra_channel_init_subdevices using ‘sd->name’.

But I do not see for now where sd->name is initialized to “imx264” instead of “imx264 spi1.1”

12

I have now discovered that my sensor is known as “imx264 spi1.1”, but the subdev initialized using v4l2_spi_subdev_init is called simply “imx264”. Which name does nvcamera-daemon need ?
Must both names be identical ?

13

Should be use the name that query from v4l2 IOCTL, I think if you have multiple sensor register name should be change by the kernel driver may be add the bus name and number automatically.

14

Actually, the problem is that ‘v4l2_spi_subdev_init’, which should be equivalent for SPI devices to ‘v4l2_i2c_subdev_init’ for I2C devices, does not set similar names as the ones set by ‘v4l2_i2c_subdev_init’. ‘v4l2_i2c_subdev_init’ produces something like “imx264 30-0010”, but ‘v4l2_spi_subdev_init’ produces only “imx264” :(
This is still so in current 4.18 upstream kernel sources.

15

I think you should be able to do the same like i2c initial if you need multiple SPI sensor support.

16

Does nvcamera-daemon need “devname” to have the “imx264 30-0010” syntax or is “imx264 spi1.1” accepted by nvcamera-daemon ?

17

I wrote a custom driver for the (I2C based) Leopard Imaging LI-M021C-MIPI. Here is the device tree file if you want to take a look.

https://github.com/DaxBot/daxc02/blob/master/tegra210-daxc02.dtsi

The sensor driver programming guide is much better than it used to be, but sometimes you have to spend time grep’ing the kernel to find examples of what you want to do. Especially where the device tree is concerned.

“devname” is used by the debugging interface, you’ll see it in dmesg, I don’t think it plays a part in anything else.

“proc-device-tree” is the device tree path to the relevant node. So the example you linked

proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/imx185_a@1a"

would correspond to a dtsi that looks something like this:

{
    i2c@3180000 {
        tca9546@70 {
            i2c@0 {
                imx185@1a {
                ...
                };
            };
        };
    };
};

I don’t think a SPI sensor would be that different from an I2C based one as long as you have all the proper controls and callbacks. Note that most of the controls in the sample driver that seem like they should be optional are in fact required and will cause the ISP to crash or not work if not implemented in some way. For example TEGRA_CAMERA_CID_HDR_EN and TEGRA_CAMERA_CID_GROUP_HOLD are required even if you leave the implementation blank.

18

By the way what camera module are you using? Or is it a custom one? Leopard Imaging has an imx264 module you might consider testing with.

19

Hi Atrer,

actually, from the answer of ShaneCC, devname must be set to the value one gets using ‘v4l2-ctl -D’ in the ‘Card type’ entry after the "vi-output, " part. So, if one gets

Card type     : vi-output, imx264

devname must be set to “imx264”

Without that, nvcamera-daemon will not find the sensor, spit a terse error message followed by useless debug messages and finally crash with a segmentation fault.

grepping in the kernel sources I have found that that value is set by v4l2_i2c_subdev_init or v4l2_spi_subdev_init. While v4l2_i2c_subdev_init does set a unique name, matching the one appearing in dmesg for messages generated by dev_info and friends (e.g. imx185 30-0010), v4l2_spi_subdev_init does a poor job, copying only the driver name, but not the dev_name(), yielding e.g. “imx264”. As I plan to use more than one sensor, I have fixed that temporarily in my imx264 driver to give e.g. “imx264 spi1.1”

Our board is a custom one.