I’ve been configuring the TX2 for use with the TC358743 driver built into the 4.4 kernel. So far this seems to be working ok with a few tweaks to the clock in the driver.
If I start the kernel and then load in the driver it shows the “entity not bounded” for the nvcsi module, but the driver loads and initialises the devices, however there are no /dev/videoX nodes created. If I build the driver into the kernel, then it fails to boot, sometimes simply stopping without any output and sometimes showing an error at tegra_vi_graph_init+0x124 which then shows the exception tree starting at el1_da+0x1b.
From the device tree point of view I’ve got my TC358743 piped to the nvcsi module and then the output of the nvcsi a port of vi@15700000. I assume this is the correct path for the TX2, the nvcsi didn’t exist in the TX1 and it simply went straight to the vi.
Any help in debugging this would be appreciated. I’m building my sources from the r27.1.0_sources.tbz2 tarball.
/* Find the remote entity. */
ent = tegra_vi_graph_find_entity(vi, link.remote_node);
if (ent == NULL) {
dev_err(vi->dev, "no entity found for %s\n",
link.remote_node->full_name);
v4l2_of_put_link(&link);
ret = -EINVAL;
break;
}
if (NULL == ent->entity) {
dev_dbg(vi->dev, "entity not bounded %s\n",
link.remote_node->full_name);
continue;
}
Makes use of the vi->notifier pointer, so I don’t believe this is where the memory fault is coming from.
The strange thing is that if I simply remove the completion notification the fault also occurs. I’ve been trying to compile the vi graph as a kernel module rather than a builtin so that I can debug it easier than re-flashing the board every time, however there seem to be a lot of cross-references to this module within the Tegra186 configuration that makes this almost impossible. Any ideas on how to progress from here?
Hi aie
Suppose the problem should be the device tree have problem to cause your problem because these code is parsing the device tree to get the config. My suggestion is checking device tree first and compare with the reference sensor DT to figure it out.
I found the problem… It was that the num-channels was being incorrectly set to 1 rather than 6. Using the override syntax in the DTSI (&csi_base) I was able to set it to 6 and that sorted the memory fault which was obviously being caused by accessing the channels that didn’t exist…
Now I just have to fix the EDID in the driver. For reference it’s this:
For reference, I had to comment out the line that calls tc358743_s_ctrl_detect_tx_5v in enable_edid. I think this is because it’s being called from the handler context and is trying to recursively take the non-recursive mutex. However, you can’t simply set the value as this is not the only code path to this line, therefore I took the decision to just leave that control with an incorrect value as it doesn’t really matter all that much…
Finally got it to work… You need to set the clock to 27000000 if it’s not already. Also implement the framesizes and framerates methods of video_ops. I used the TC358840 driver to help a lot.
you could refer to the camera sensor device tree under below,
r28.1_sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-modules/tegra186-camera-li-mipi-adpt-a00.dtsi
static int tc358743_s_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edid)
in old driver
if (tx_5v_power_present(sd))
tc358743_enable_edid(sd);
change it to:
tc358743_enable_edid(sd);
Cause when your probe almost done, tx_5v_power_present(sd) always return false and set EDID will fail.
3. Set EDID in the probe function.
4. Add tc358743 driver as built in module
And there are 1 things that i have made with the device tree:
in file “tegra210-jetson-cv-base-p2597-2180.dts”
remove the line:
After that, rebuild kernel and flash the os or replace some files have been built in current system
Image,zImage
tegra210-jetson-cv-base-p2597-2180.dtsi
Reboot system and check dmesg to see if it has log related to probe function of tc358743
dmesg | grep tc358743
If everything ok, you will see some /dev/video*