TC358743 on TX2


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.

Thanks, Chris.

Hi aie
That could be caused by the device try, You can check this source to find out what cause the problem.


/* 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",
			ret = -EINVAL;

		if (NULL == ent->entity) {
			dev_dbg(vi->dev, "entity not bounded %s\n",

I checked the source, the line is 577 of graph.c:

ret = tegra_vi_graph_notify_complete(&vi->notifier);

The device itself functions correctly on the TX1, therefore I don’t believe it to be a hardware issue.

A line prior to this in the function:

v4l2_async_notifier_register(&vi->v4l2_dev, &vi->notifier);

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.

Hi Chris,

I am also trying to connect a TC358743 to a Jetson TX2.

Could you share the changes that were required for the TC358743 driver?



I wonder if the issue is my choice of clock, I’m using extperiph1 as used by the examples. Would that be the clock of choice?

I’ve not changed the driver at all currently. Just had to ensure that is not resetting the GPIO.

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:

[ 298.489786] Unable to handle kernel paging request at virtual address ffff00c1f61319b8
[ 298.497760] pgd = ffffffc1e066b000
[ 298.501222] [ffff00c1f61319b8] *pgd=0000000000000000, *pud=0000000000000000
[ 298.508266] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 298.513833] Modules linked in:
[ 298.516900] CPU: 0 PID: 1954 Comm: v4l2-ctl Not tainted 4.4.15 #2
[ 298.522986] Hardware name: quill (DT)
[ 298.526643] task: ffffffc0708f6400 ti: ffffffc1cfca8000 task.ti: ffffffc1cfca8000
[ 298.534125] PC is at mutex_lock+0x14/0x68
[ 298.538135] LR is at tc358743_s_ctrl_detect_tx_5v+0x30/0x60
[ 298.543699] pc : [] lr : [] pstate: 60000045
[ 298.551081] sp : ffffffc1cfcabb80
[ 298.554390] x29: ffffffc1cfcabb80 x28: ffffffc1ecee8b00
[ 298.559718] x27: ffffffc1e55f7b00 x26: 0000000000000000
[ 298.565043] x25: ffffffc1cfcabd50 x24: 0000000000000000
[ 298.570368] x23: ffffffc0011efc58 x22: ffffffc0011efd10
[ 298.575695] x21: 0000000000000000 x20: 0000000000000001
[ 298.581020] x19: ffff00c1f61319b8 x18: 0000000000000000
[ 298.586343] x17: 000000000000adca x16: 000000000000adca
[ 298.591667] x15: 0000000000000000 x14: 0000000000000000
[ 298.596992] x13: 0000000000000005 x12: 0000000000017462
[ 298.602318] x11: 0000000000017462 x10: 0000000000000400
[ 298.607642] x9 : 0000000000000400 x8 : 0000000000000400
[ 298.612965] x7 : ffffffc1ffcab518 x6 : ffffffc1f58f9860
[ 298.618291] x5 : 0000000000000000 x4 : ffffffc0708f6400
[ 298.623615] x3 : ffffffc1cfca8000 x2 : 0000000000000000
[ 298.628939] x1 : ffffffc0708f6400 x0 : ffff00c1f61319b8

[ 298.635753] Process v4l2-ctl (pid: 1954, stack limit = 0xffffffc1cfca8020)
[ 298.642615] Call trace:
[ 298.645062] [] mutex_lock+0x14/0x68
[ 298.650108] [] tc358743_s_ctrl_detect_tx_5v+0x30/0x60
[ 298.656714] [] tc358743_enable_edid+0x70/0xc0
[ 298.662627] [] tc358743_s_edid+0xf4/0x148
[ 298.668196] [] tegra_channel_s_edid+0x34/0x50
[ 298.674110] [] __video_do_ioctl+0x1bc/0x2c8
[ 298.679848] [] video_usercopy+0x1a0/0x590
[ 298.685412] [] video_ioctl2+0x14/0x20
[ 298.690631] [] v4l2_ioctl+0xe8/0x118
[ 298.695765] [] do_vfs_ioctl+0x33c/0x5f0
[ 298.701156] [] SyS_ioctl+0x8c/0xa0
[ 298.706118] [] el0_svc_naked+0x24/0x28

Hi Chris,

Thanks for the information.


Where is the reference DT located?

I am actually trying to replace the OV5693 with TC357843.

Does this require only changes in DT?

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.

I’m trying to port driver tc358743 from kernel 3.10.96 to 4.4.38. Can you tell me how to write device tree for it?

hello haihoangsoftware,

you could refer to the camera sensor device tree under below,

Could anyone who has had success with the driver for TC358743 share the code or changes required for it to work?

Here is my code.
The driver and device tree work for TX1, jetpack 3.0, kernel 3.10.96, not tested on TX2.
There are 3 things that i have made with the driver source code.

  1. Declare EDID
  2. There is the line in
static int tc358743_s_edid(struct v4l2_subdev *sd,
				           struct v4l2_subdev_edid *edid)

in old driver

if (tx_5v_power_present(sd))

change it to:


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:

  1. in file “tegra210-jetson-cv-base-p2597-2180.dts”
    remove the line:
#include "tegra210-plugin-manager/tegra210-jetson-cv-plugin-manager.dtsi"

add the line:

#include "tegra210-tc358743.dtsi"

After that, rebuild kernel and flash the os or replace some files have been built in current system

  1. Image,zImage
  2. 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*