Hi NVIDIA community,
Our application involves integrating the HDMI camera with NVIDIA Xavier NX processor. We observed that there is a I2C driver for TC358840 and LT6911UXC present in L4T 32.6.1, but the device tree information is not available for the same. Could someone kindly assist us in locating the appropriate dtsi files?
Regards,
Natesan S
Any problem to reference to TC358840?
Hi,
TC358840 DTSI also not available.
Regards,
Natesan S
Suppose you need implement a driver for it.
Please reference to the programing guide.
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/CameraDevelopment.html
I am curious, do you know the exact driver used with this device? If you can insmod (or modprobe) that driver manually, and it fails to load, then the issue is quite different from not finding the driver. During module load the data and arguments passed to a driver to work with the device can be wrong, and that can cause load to be rejected (in combination with hot the hardware behaves); or the driver can be missing. The former (rejecting load) might be caused by device tree, while the latter (driver missing) implies the device tree might not be at fault.
Incidentally, configuration of a kernel uses “symbols” related to each feature or driver. They start with “CONFIG_”. You can see the running kernel’s configuration via:
zcat /proc/config.gz
You could assume part of that chip name is in the symbol, and search for it this way (if the number is in the symbol):
zcat /proc/config.gz | grep -i 358840
If the output is “=y”, then the driver is integrated, and not a module (so you cannot insmod or modprobe something which is not dynamically loadable/unloadable, but it is there). If the output is “=m”, then this is a module format which can dynamically load. If the output is commented out or “=n”, then you have to add the driver.
If this part is “=y” or “=m”, then you need to include that information. If it is “=m”, then you also need to monitor “dmesg --follow” while trying to modprobe the module, and note both command line error messages and the new log lines appearing as a result of the module insert attempt. Then read the rest of this more or less as background; if there is no available device tree fragment, then you probably need to understand what follows. Or if there is a published fragment, but not part of this kernel, it is useful to understand what follows. Mostly what follows will lead to more questions.
For the case of “=y”, then the device tree would be involved for non-plug-n-play devices. Device tree fragments would not necessarily have a name associated with the chipset. Usually a drivers a “name@...hex address...”. Within that node is a “compatible” entry. It is the compatible entry which has a comma-delimited list of drivers which can be used on that device at that physical address.
I noticed on one kernel L4T R32.x that there is some out of tree content in the “drivers/media/i2c/” area. This would imply that the NVIDIA kernel source had been downloaded, and configuration within a regular kernel build would be used to enable this (if you don’t already have the driver). The build would have been from the regular kernel source, but that configuration would trigger some “../” inside the build path (via a “_ddot_” macro) which descends below the regular source, and then ascends into the “nvidia/drivers/media/i2c/” to compile the driver (you don’t necessarily need to do this, you might have the driver; see the check of config.gz).
If one were to properly configure the source code from NVIDIA to match the running system’s configuration (including CONFIG_LOCALVERSION, which you can see in the suffix of the command “uname -r”, and is normally “-tegra”), and if you are to successfully propagate that configuration, then building the “dtbs” target, then the device tree would be assembled with correct arguments for any driver which was configured and which is matching the NVIDIA carrier board design. The tree is not part of the kernel, but because fragments of device tree are needed only for drivers which are present (and these should be present only for hardware they work with), it is convenient that the device tree be compiled based on kernel configuration.
Even if you don’t use a new kernel build or module build, and even if you don’t use the generated device tree, then this might be useful to examine for that fragment. On the other hand, it might be a waste of time because this particular device might not have a known supported device tree fragment. One has to know the physical address and arguments to pass before you can create a fragment. This will preexist only in cases where the hardware is present by default on some commercial hardware (there is no way the kernel source can know where to find hardware which does not exist in common cases).
Hello,
We appreciate your prompt response.
It appears that there might have been a miscommunication in our previous correspondence. We had mentioned that the drivers (tc358840.c and LT6911UXC.C) are available in the L4T 32.6.1 BSP source. However, due to the unavailability of the device tree (DTSI) for these devices, we have encountered difficulties in integrating them with the Xavier NX platform. If the driver and DTSI for respective devices are available, it would greatly assist us in achieving successful integration.
Thank you for your attention to this matter.
Best regards,
Natesan S
Please check the programing for device tree and driver configure.
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/CameraDevelopment.html
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.