Hardware platform: jetson-agx-orin-xavier-devkit
It is ready to transplant a new sensor support. The current imx185 sensor driver supported by the development board is changed to imx565. i2 can read and write sensor registers normally and also detect vide0 devices.When collecting data through v4l2, the kernel will print error logs:
there shows the failure with PHY interrupts, the error code 0x44 indicate there’re more than one bit error has detected on data-lane; the error code 0x48 it shows there’s failure with the LP sequence.
furthermore,
since you’re based-on IMX185 to develop your IMX565 sensor driver. could you please also check Sensor Pixel Clock session to review the clock settings in order to avoid potential issues.
I refer to Applications Using V4L2 IOCTL Directly and use the following command:
v4l2-ctl --set-fmt-video=width=3840,height=2160,pixelformat=RG12 --stream-mmap --set-ctrl=sensor_mode=0 --stream-count=10000 -d /dev/video0 --stream-to=185.raw
The mistakes haven’t changed.
This is the IMX565 device tree configuration:
tegra-camera-platform {
compatible = "nvidia, tegra-camera-platform";
/**
* Physical settings to calculate max ISO BW
*
* num_csi_lanes = <>;
* Total number of CSI lanes when all cameras are active
*
* max_lane_speed = <>;
* Max lane speed in Kbit/s
*
* min_bits_per_pixel = <>;
* Min bits per pixel
*
* vi_peak_byte_per_pixel = <>;
* Max byte per pixel for the VI ISO case
*
* vi_bw_margin_pct = <>;
* Vi bandwidth margin in percentage
*
* max_pixel_rate = <>;
* Max pixel rate in Kpixel/s for the ISP ISO case
*
* isp_peak_byte_per_pixel = <>;
* Max byte per pixel for the ISP ISO case
*
* isp_bw_margin_pct = <>;
* Isp bandwidth margin in percentage
*/
num_csi_lanes = <4>;
max_lane_speed = <1500000>;
min_bits_per_pixel = <12>;
vi_peak_byte_per_pixel = <2>;
vi_bw_margin_pct = <25>;
isp_peak_byte_per_pixel = <5>;
isp_bw_margin_pct = <25>;
/**
* The general guideline for naming badge_info contains 3 parts, and is as follows,
* The first part is the camera_board_id for the module; if the module is in a FFD
* platform, then use the platform name for this part.
* The second part contains the position of the module, ex. "rear" or "front".
* The third part contains the last 6 characters of a part number which is found
* in the module's specsheet from the vender.
*/
modules {
module0 {
badge = "imx185_bottom_liimx185";
position = "bottom";
orientation = "0";
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = "v4l2_sensor";
/* Driver v4l2 device name */
devname = "imx185 30-001a";
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = "/proc/device-tree/i2c@3180000/imx185_a@1a";
};
};
};
};
since you’re based-on IMX185 to develop your IMX565 sensor driver.
had you also update the compatible property as identical string with IMX565 sensor driver?
for example,
i2c@3180000 {
tca9546@70 {
i2c@0 {
imx185_a@1a {
compatible = "sony,imx185"; <== it should also updated.
is this IMX565 sensor actually used the same CSI port as IMX185?
can you also confirm all of the power supply had given correctly?
hello JerryChang
I understand that the compatible field should be just an identifier that associates imx185.c with imx185.dts, and that even if it is not modified, it will not affect my fetching stream. Our adapter board does not use tca9546 in the design, so imx185_a@1a is directly hung under i2c@3180000, as shown in the following:
BTW,
system level clock configurations were based-on device tree settings.
for bring-up purpose. you may execute below commands to boost all the VI/CSI/ISP clocks to avoid some clock related issue.
for example,
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
I reworked the driver and device tree, replacing all references to imx185 with imx565. Use the command line you gave to increase the clock rate, still no change, the error is as follows:
What I am confused about is that if the kernel connects sonsor, CSI and VI, how can the binding relationship between them determine that the binding is correct?
device topology looks correct… Sensor → CSI → VI.
may I also know what’s the latest VI tracing logs? are you still seeing the same PHY interrupts with 0x44?
it’s LP sequence error detected on data lane. this usually an issue on sensor side.
note,
there’s sequence, LP11->LP01->LP00->LP11. when moving from LP to HS. the settle time determine how many cscil clock cycles to wait after LP00.
hence…
you may configure cil_settletime, it’s the property to tune the transition time from LP to HS mode.
please see-also developer guide for more details of cil_settletime property.
hello JerryChang, Sorry for replying so late.
By changing the cil_settletime parameter to 120, the situation didn’t settle, and the same error message was reported:
(1) can you obtain correct sensor format dumps by… $ v4l2-ctl -d /dev/video0 --list-formats-ext
(2) you may ignore the test failure of VIDIOC_G/S_PARAM in compliance test.
(3) however, please dig into the sensor driver to examine the test item for buffer ioctls. it should be root cause of your issue.
hello JerryChang,
According to the command line output you give( format looks okay):
This is based on the official imx185 driver. How can I modify it to test the buffer ioctls. nv_imx185.c (21.7 KB) imx185_mode_tbls.h (19.7 KB)
these vb2_ioctl_xxx() functions are simple helper functions that you can use in your struct v4l2_file_operations, struct v4l2_ioctl_ops and struct vb2_ops.
that failure might be calling filehandle to do queuing operation is prohibited.
What do I have to do to enable this file handle. Or if this error will affect my ability to get a video stream. That is, whether the following error information is related to this error:
