ADV7482 and Jetson TX1

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Dear freinds, is it possible to use i2c_cam for adv7482?

2

Dear all.

I have modified adv7482 driver and post it to Jetson TX1 and when system loaded, it created /dev/video0 but when i read data from video link, i got message from system log:
“Not detect any video input signal”
Here is my driver source:
https://drive.google.com/open?id=1elVpetMgy9Rb3sFWNI0nFod10yjRZASU
Can some one tell me where i am did not right? Please help me.

3

Dear haihoangsoftware, is it possible use i2c_cam for adv7482?

4

Dear 9iggor6.

I dont really understand your question.
Can you tell me what is i2c_cam?
ADV7482 is a brigde convert signal from HDMI/ANALOG/8bit data to CSI-2

5

ADV7482 has i2c for control commands. What is the number i2c, that you use for control adv7482?

6

It depends on which board you plug it in. I cannot detect i2c address using command

i2cdetect -y -r [i2c port]

but i can send and receive from ADV7842.
For example i plug ADV7482 (contain address 0x70) with Jetson TX1 carrier board J120 with CSI-2 port EF, i cannot detect i2c address on i2c-2 but i can set register 0x10 with value 0x6e to ADV7482 via this port with command

i2cset -y -r 2 0x70 0x10 0x6e

and read register value back with command

sudo i2cget -y 2 0x70 0x10
7

I encountered the same problem. And one more question. Are you connect adv7482 as module or as part of kernel?

8

It’s built in kernel. Of course

9

Good day, somebody try use this drivers [url]https://github.com/torvalds/linux/tree/master/drivers/media/i2c/adv748x[/url] with TX1?

10

Can i see your device tree?

Here is my driver and device tree
https://drive.google.com/open?id=1elVpetMgy9Rb3sFWNI0nFod10yjRZASU
I. Add driver
And how i add the driver with TX1 and carrier board J120 Auvidea:

  1. add those lines to kernel_source/drivers/media/i2c/Kconfig
    config VIDEO_ADV7482
    tristate “ADV7482 Analog decoder”
    depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
    select HDMI
    —help—
    Support for the ADV7482 Analog to MIPI CSI-2 bridge.

    To compile this driver as a module, choose M here: the
    module will be called ADV7482.

  2. add this line to kernel_source/drivers/media/i2c/Makefile
    obj-$(CONFIG_VIDEO_ADV7482) += adv7482.o

  3. define in kernel/kernel-4.4/include/uapi/linux/v4l2-controls.h
    V4L2_CID_USER_ADV7482_BASE (V4L2_CID_USER_BASE + 0x1080)
    II. Add device tree
    After add the driver, you will see ADV7482 Analog decoder when search “ADV7482” after run “make xconfig”
    Now you have to add device tree by import tegra210-tc358743.dtsi to device tree folder and edit file tegra210-jetson-cv-base-p2597-2180-a00.dts like this link
    tegra210-jetson-cv-base-p2597-2180-a00.dts - Google Drive
    III. Build and update
    Speed up building process by cross build

  4. make zImage

  5. make dtbs

  6. overwrite zImage and Image in /boot/ folder

  7. overwrite tegra210-jetson-cv-base-p2597-2180-a00.dtb in /boot/ folder

  8. change dtb file to load with system by edit extlinux.conf in /boot/extlinux and change FDT to

FDT /boot/tegra210-jetson-cv-base-p2597-2180-a00.dtb
  1. Plug ADV7482 to jetson TX1 and reboot TX1 to take effect.
11

Just FYI, in newer releases the FDT entry no long works as expected. This would still work on older releases, but when the TX1 and TX2 started using the same release the merge resulted in some of the device tree being required at stages earlier than U-Boot. Since those stages cannot read ext4 file systems the tree was moved to a partition. You might want to browse “/proc/device-tree” after reboot and see if the changes actually made their way in.

12

Hi.

I forgot to tell you that i am using jetpack 3.0 for Jetson TX1. I tried to port driver of TC358743 to Jetson TX1 install jetpack 3.1 and had to use another way to make the driver work based on [url]https://developer.ridgerun.com/wiki/index.php?title=Compiling_Jetson_TX1/TX2_source_code[/url]

13

My device tree
[url]Oops!

14

I have not looked at the specific tree requirements, but does that tree include the changes you made? The goal is to see if the “/proc/device-tree/” content reflects any edits you made and installed…there are times when the install did not actually go into effect because of changes in device tree install procedures over the various releases. If you are going by your edits and not confirming the edits were actually installed, then confirmation of edit is the next step.

15

In the boot process, I watch:

[   10.159267] vi vi: initialized                                               
[   10.159630] vi vi: parsing node /host1x/vi                                   
[   10.159635] vi vi: handling endpoint /host1x/vi/ports/port@0/endpoint        
[   10.159708] vi vi: parsing node /i2c@546c0000/adv7482_ef@70                  
[   10.159714] vi vi: handling endpoint /i2c@546c0000/adv7482_ef@70/ports/port@t
[   10.159971] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have dee
[   10.160011] platform 5.regulator: Driver reg-fixed-sync-voltage requests prol
[   10.160304] platform 7.regulator: Driver reg-fixed-sync-voltage requests prol
[   10.160532] platform d.regulator: Driver reg-fixed-sync-voltage requests prol
[   10.160636] [dram-timers] DRAM derating cdev registered.                     
[   10.160644] Disable partitions left on by BL                                 
[   10.160647]     sata

But in the /dev folder video0 doesn’t appear

16

Tried to add this line

sd->dev = &client->dev;

before this line

ret = v4l2_async_register_subdev(sd);

I found /dev/video0 not created because of that.

17

That file (“/dev/video0”) is not a real file. That file is a reflection of the kernel driver detecting and loading for a specific piece of hardware which that particular driver is capable of handling. The file series “/dev/video#” exists only for USB “standard” video cameras.

The i2c component could be a different issue…although it is physically one camera, in reality there can be multiple devices related to one camera. However, I can’t imagine i2c setup for a USB camera. The presence of “/dev/video#” would imply you are working with a USB camera, but talk of i2c would tend to imply this is not USB. If this is not a USB camera, then you would use a different driver, and that driver would create some other file with a different name. If your software is expecting a camera with a related file name such as “/dev/video0”, then I suspect the software only works with USB cameras.

From what I can tell from earlier steps in the forum thread the goal is to install a non-USB driver and camera setup. I am not a “camera guy”, but if you have followed steps above, then the question might now be one of “how to use” the camera instead of one of “how to get /dev/video0”. Someone else would need to answer that, though I am guessing it will be via a gstreamer pipeline.

18

In my understand, the /dev/video# file created because of the driver register v4l2 sub dev to the v4l2 core.
I have success in connect TC358743 with Jetson TX1 in J100,J120 carrier board with that way and i can get data from /dev/video# and when i talk to /dev/video#, the command send directly to the TC358743 via driver with defined function involve with v4l2_subdev_pad_ops, v4l2_subdev_video_ops, v4l2_subdev_core_ops.
When i connect USB camera belong with another i2c camera, the id of /dev/video# will increase like camera USB equal /dev/video0, other i2c camera will equal /dev/video1,/dev/video2,…
With i2c camera, i can read data from gstreamer or from v4l2 api.

19

You are correct about the video# increasing, but that is purely for USB. When you speak of an i2c camera this implies a non-USB camera. There is possibly some secondary i2c port unrelated to USB, but what I am wondering is if everything “camera” is USB? If not, then there will be no possibility of the video# being incremented with a new camera (well, someone could write some adapter code to make the camera work like that if the camera conforms to the UVC interface).

Gstreamer would probably have different options for something like a CSI source versus a USB UVC source. I couldn’t tell you what that is, but if you wait for a video# to show up on a non-USB camera you’ll be waiting forever.

20

Jetson TX1 development kit has the CSI-2 camera and if i want to capture video from it i have to run gstreamer nvcamerasrc and it absolutely not /dev/video# but NVDIA not explain what is nvcamerasrc.
It has file /dev/video0 but if i only read black frame from it with gstreamer. So it’s take me a lot of time to create video link for our CSI-2 camera board and i finally choose to register camera via v4l2 core to create video link /dev/video* and process data through it. This is the easiest way to write driver for own developed camera board.
I have sucess with TC358743 on both TX1 and TX2, ADV7482 on TX1 with that way.