Strange problem with rockchip-isp1 driver and ADV7280

597 views
Skip to first unread message

Wojciech Zabolotny

unread,
Jan 29, 2020, 6:32:02 PM1/29/20
to linux-rockchip
Hi,

I need to connect the ADV7280A-M based converter to the RK3399-based SBC.
I tried to do it with the old 4.4.157 kernel and also with the newest
rockhip/isp/v13 version from collabora.
Results are the same. The sensor and ISP1 get configured, but then
ISP1 stops waiting for data.
I have verified with the scope, that the data on CSI-2 are transmitted.
The ov5647-based camera works in the same setup.
I have described the problem on the Radxa forum (
https://forum.radxa.com/t/adv7280m-with-rock-pi-4b-problems/2504 ),
but have received no answer. Unfortunately, I do not have any access
to the full ISP1 documentation, so I do not know how to check what is
it complaining about.
All I have is the information from isp1-related sources and headers.
I'll appreciate any hints how to isolate and fix the problem.

With best regards,
Wojtek

Wojciech Zabolotny

unread,
Jan 30, 2020, 6:51:47 AM1/30/20
to linux-rockchip
How can I check and interprete the status of the ISP1, when it is ignoring my data?
Of course, I can extend the original driver with the "device attribute", that reads the ISP1 status.
Probably the code like below should do the trick:

static ssize_t isp1_stat_show(struct device *dev, struct device_attribute *attr, char *buf)
{
  struct rkisp1_device * rkisp1_ptr;
  rkisp1_ptr = container_of(dev,struct rkisp1_device,dev);
  sprintf(buf,PAGE_SIZE,"%d",rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS));
  return strlen(buf);
}

DEVICE_ATTR_RO(isp1_stat);

The only question is, if RKISP1_CIF_ISP_MIS register is the right one, which I should check for
errors in operation of ISP1?
Unfortunately, the rkisp1-regs.h header file lacks any documentation.

In fact I think that we should drop the idea to use the RK3399-based platform in our project
and replace it with iMX8, which seems to be better documented.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Jan 30, 2020, 1:21:12 PM1/30/20
to linux-rockchip
I have received a feedback from Helen Koike, the developer of the rkisp1 driver.
I'll send the update to this thread as soon as the problems with using ADV7280A-M and rkisp1
are resolved.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 1, 2020, 11:04:04 AM2/1/20
to linux-rockchip
Up to now I have added a definition of the format UYVY8_2X8 proposed by Helen Koike: https://github.com/wzab/linux/blob/f7eb7489387b24bd539fb375e44821c201f6948c/drivers/staging/media/rkisp1/rkisp1-isp.c#L172
I have also added the code that allows checking the ISP1 registers during the acquisition (I don't know why it hangs the system when acquisition is not running): https://github.com/wzab/linux/blob/f7eb7489387b24bd539fb375e44821c201f6948c/drivers/staging/media/rkisp1/rkisp1-dev.c#L28

When I start acquisition from ADV7280A-M, I get the following results:
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000000

When I start the acquisition from OV5647, I get the following:
# ( v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-skip=200 --stream-count=1 & ) ; sleep 1 ; cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
MIS=00000000
IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
# <<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

So it seems that for certain reason the ISP1 is not started (CTRL=0) and even not configured for acquisition, but no error is reported.
I'll update the status as soon as I have any new findings or hints.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 1, 2020, 11:13:25 AM2/1/20
to linux-rockchip
OK. I have mistaken. CTRL is not 0 in case of ADV7280. It is 0x95 instead of 0x97:

/* ISP_CTRL */
#define RKISP1_CIF_ISP_CTRL_ISP_ENABLE                  BIT(0)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_RAW_PICT           (0 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_ITU656             BIT(1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_ITU601             (2 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_BAYER_ITU601       (3 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_DATA_MODE          (4 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_BAYER_ITU656       (5 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_MODE_RAW_PICT_ITU656    (6 << 1)
#define RKISP1_CIF_ISP_CTRL_ISP_INFORM_ENABLE           BIT(4)
#define RKISP1_CIF_ISP_CTRL_ISP_GAMMA_IN_ENA            BIT(6)
#define RKISP1_CIF_ISP_CTRL_ISP_AWB_ENA                 BIT(7)
#define RKISP1_CIF_ISP_CTRL_ISP_CFG_UPD_PERMANENT       BIT(8)
#define RKISP1_CIF_ISP_CTRL_ISP_CFG_UPD                 BIT(9)
#define RKISP1_CIF_ISP_CTRL_ISP_GEN_CFG_UPD             BIT(10)
#define RKISP1_CIF_ISP_CTRL_ISP_GAMMA_OUT_ENA           BIT(11)
#define RKISP1_CIF_ISP_CTRL_ISP_FLASH_MODE_ENA          BIT(12)
#define RKISP1_CIF_ISP_CTRL_ISP_CSM_Y_FULL_ENA          BIT(13)
#define RKISP1_CIF_ISP_CTRL_ISP_CSM_C_FULL_ENA          BIT(14)

So only the RAW_PICT is not switched on.
The problem however is why RIS is not set (0x80 corresponds to bit:
#define RKISP1_CIF_ISP_H_START                          BIT(7)
)
and why ACQ_PROP is not set.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 1, 2020, 11:18:52 AM2/1/20
to linux-rockchip
Thats not the RAW_PICT bit. Thats
RKISP1_CIF_ISP_CTRL_ISP_MODE_ITU601 in case of ADV7280
and
RKISP1_CIF_ISP_CTRL_ISP_MODE_BAYER_ITU601 in case of OV5647
So that makes a sense.
However the difference in RIS and ACQ_PROP is annoying.

Wojciech Zabolotny

unread,
Feb 1, 2020, 11:42:35 AM2/1/20
to linux-rockchip
In case of ISP_RIS register during the acquisition from OV5647, its value changes.
Sometimes I get 0x80, sometimes 0x4080, sometimes 0x4c080.
So it is obviously a register that shows the current status (interrupt status?) of the ISP1.
Unfortunately, in case of ADV7280 it is always 0...

Wojciech Zabolotny

unread,
Feb 1, 2020, 1:11:26 PM2/1/20
to linux-rockchip
Well, I have reverted the cheat saying that ADV7280 produces YUYV8_2X8 instead of UYVY8_2X8
It is not needed after the definition of the format UYVY8_2X8 was added by Helen.
In fact, that cheat was probably incorrect, as YUYV8_2X8 is defined as:
{
.mbus_code = MEDIA_BUS_FMT_YUYV8_2X8,
.fmt_type = RKISP1_FMT_YUV,
.direction = RKISP1_DIR_SRC,
},
while UYVY8_2X8 is defined as:
{
.mbus_code = MEDIA_BUS_FMT_UYVY8_2X8,
.fmt_type = RKISP1_FMT_YUV,
.mipi_dt = RKISP1_CIF_CSI2_DT_YUV422_8b,
.yuv_seq = RKISP1_CIF_ISP_ACQ_PROP_CBYCRY,
.bus_width = 8,
.direction = RKISP1_DIR_SINK,
},

especially the .direction field looks suspicious.
After that change, the dump of registers during the acquisition looks better:

# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100

(ACQ_PROP is set).
But data are not flowing, and acquisition still freezes.

Wojciech Zabolotny

unread,
Feb 1, 2020, 1:24:17 PM2/1/20
to linux-rockchip
I have found one interesting thing. After each attempt to start image capture, the counter of dropped frames is increased by 2:

# for i in /sys/kernel/debug/rkisp1/* ; do echo $i `cat $i` ; done
/sys/kernel/debug/rkisp1/data_loss 0
/sys/kernel/debug/rkisp1/mipi_error 0
/sys/kernel/debug/rkisp1/mp_frame_drop 14
/sys/kernel/debug/rkisp1/mp_stop_timeout 7
/sys/kernel/debug/rkisp1/pic_size_error 0
/sys/kernel/debug/rkisp1/sp_frame_drop 0
/sys/kernel/debug/rkisp1/sp_stop_timeout 0
/sys/kernel/debug/rkisp1/stats_error 0

# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1
^C

# for i in /sys/kernel/debug/rkisp1/* ; do echo $i `cat $i` ; done
/sys/kernel/debug/rkisp1/data_loss 0
/sys/kernel/debug/rkisp1/mipi_error 0
/sys/kernel/debug/rkisp1/mp_frame_drop 16
/sys/kernel/debug/rkisp1/mp_stop_timeout 8
/sys/kernel/debug/rkisp1/pic_size_error 0
/sys/kernel/debug/rkisp1/sp_frame_drop 0
/sys/kernel/debug/rkisp1/sp_stop_timeout 0
/sys/kernel/debug/rkisp1/stats_error 0
#

Wojciech Zabolotny

unread,
Feb 1, 2020, 2:42:06 PM2/1/20
to linux-rockchip
I have added a counter, that should count the correctly received frames:
Unfortunately, it still counts 0 frames.
So it looks, like nothing is received from MIPI?
Is it possible to monitor the status of MIPI reception in ISP1?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 1, 2020, 4:08:41 PM2/1/20
to linux-rockchip
I have added two more registers to my debug output. The results are
for ADV7280:
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000

For OV5647:
MIS=00000000
IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000

So generally the settings are the same. Additionally MI_BYTE_CNT doesn't count bytes also for OV5647. Does it mean that this register is not a byte counter for bytes received from MIPI?

Wojciech Zabolotny

unread,
Feb 1, 2020, 6:39:44 PM2/1/20
to linux-rockchip
I have added MIPI registers to my debug dump.
Below are results obtained for the (running) acquisition on OV5647:
IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
 MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000

And for (stalled) acquisition from ADV7280. The oscilloscope shows data transmitted on MIPI data lane:
MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100
 MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000

The only unexplainable difference is RIS (ISP_RIS) that is always 0 for ADV7280.

Wojciech Zabolotny

unread,
Feb 2, 2020, 8:30:35 AM2/2/20
to linux-rockchip
In a desparate attempt to isolate the problem, I have tried to pretend, that ADV7280 produces SBGGR format.
The resulting code is in:
Now the initialization is done via:
media-ctl -r
v4l2-ctl -d /dev/v4l-subdev3 -s pal
media-ctl -l "28:0->1:0[1]"
media-ctl -l "1:2->6:0[1]"
media-ctl -l "6:1->12:0[1]"
media-ctl -V 1:0[fmt:SBGGR8_1X8/720x576]
media-ctl -V 1:2[fmt:YUYV8_2X8/720x576]
media-ctl -V 6:0[fmt:YUYV8_2X8/720x576]
media-ctl -V 6:1[fmt:JPEG_1X8/720x576]
v4l2-ctl --device /dev/video0 --set-fmt-video=width=720,height=576,pixelformat=YUYV

v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1

But anyway the image acquisition stalls.

Wojciech Zabolotny

unread,
Feb 2, 2020, 1:45:38 PM2/2/20
to linux-rockchip
I have found one very suspicious thing.
When I start image acquisition from ADV7280 with full debugging, I get the debug message from phy

[...]
[  387.167712] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  387.168416] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  387.169075] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  387.169689] rkisp1 ff910000.isp0: capture 0 crop disabled
[  387.170162] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[  387.170614] rkisp1 ff910000.isp0:
[  387.170614]   MIPI_CTRL 0x00060f00
[  387.170614]   MIPI_IMG_DATA_SEL 0x0000001e
[  387.170614]   MIPI_STATUS 0x00002000
[  387.170614]   MIPI_IMSC 0x03f33333

[  387.172175] rockchip-mipi-dphy-rx0 ff770000.syscon:mipi-dphy-rx0: lanes 1 - data_rate_mbps 216

[  387.174474] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  387.175061] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  387.175721] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  387.176283] rkisp1 ff910000.isp0: walk: pushing 'adv7180 4-0021' on stack
[  387.176874] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.177540] rkisp1 ff910000.isp0: walk: returning entity 'adv7180 4-0021'
[  387.178131] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[...]

When I start acquisition from OV5647, that message is NOT printed.

[...]
[  251.130368] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  251.131074] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  251.131757] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  251.132379] rkisp1 ff910000.isp0: capture 0 crop disabled
[  251.132855] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[  251.133313] rkisp1 ff910000.isp0:
[  251.133313]   MIPI_CTRL 0x00061f00
[  251.133313]   MIPI_IMG_DATA_SEL 0x0000002a
[  251.133313]   MIPI_STATUS 0x00002000
[  251.133313]   MIPI_IMSC 0x03f33333
[  251.137048] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  251.137629] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  251.138289] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  251.138852] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  251.139454] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  251.140124] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  251.140710] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[...]

It looks, like in case of preparing the system for acquisition form OV5647, rk_dphy_configure is not called?
How is it possible?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 2, 2020, 4:46:00 PM2/2/20
to linux-rockchip
I have added two messages printed at the begining of the
rk_dphy_configure and rk_dphy_power_on functions

When I start the acquisition from OV5647, I get the following debug output:
[...]
[  169.550218] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  169.551616] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  169.554037] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  169.555571] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  169.558237] rkisp1 ff910000.isp0: capture 0 crop disabled
[  169.559571] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[  169.562340] rkisp1 ff910000.isp0:
[  169.562340]   MIPI_CTRL 0x00061f00
[  169.562340]   MIPI_IMG_DATA_SEL 0x0000002a
[  169.562340]   MIPI_STATUS 0x00002000
[  169.562340]   MIPI_IMSC 0x03f33333
[  169.566257] I'm in rk_dphy_configure
[  169.567206] I'm in rk_dphy_power_on
[  169.586124] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  169.587649] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  169.590025] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  169.591393] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  169.593524] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  169.595051] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  169.597399] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  169.599109] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  169.601432] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  169.602969] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  169.605193] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  169.606884] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  169.609162] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  169.610788] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  169.612161] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  169.614494] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  169.615904] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  169.618023] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  169.619549] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  169.621643] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  169.623137] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  169.625458] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  169.627029] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[  170.697747] rkisp1 ff910000.isp0: begin graph walk at 'rk'
[  170.699365] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  170.702125] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  170.703508] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  170.705696] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)

So obviously the rk_dphy_configure is called, but phy_mipi_dphy_config_validate fails in
and therefore the rest of the code is not executed (error returned by the configure function is ignored:

So now the interesting question is: why NOT CONFIGURING phy results in successfull acquisition, while configuring it causes it to stall?

Regards,
Wojtek






Wojciech Zabolotny

unread,
Feb 4, 2020, 7:28:07 PM2/4/20
to linux-rockchip
The interesting thing is that MIPI_STATUS contains 0x2000 which means that the CSI clock lane is in ULPS mode.
When I dump the registers during the transmission, it is still in that mode, so it seems that it ignores the fact that the sensor (ADV7280) was switched on and started to transmit clock.
Is it possible, that MIPI PLL requires the CSI clock to be stable when the DPHY is configured and powered on?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 4, 2020, 7:56:53 PM2/4/20
to linux-rockchip
Well, for OV5647 I have got the following, very interesting result:

# ( v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-s
kip=50 --stream-count=1 & ) ; sleep 1 ; cat /sys/class/video4linux/v4l-subdev0/d
evice/isp1_stat
[  312.767043] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  312.767637] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  312.768329] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  312.768897] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  312.769483] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.770152] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  312.822062] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  312.822835] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  312.823496] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.824183] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  312.824785] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  312.825552] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  312.826154] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  312.826815] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  312.827401] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.828088] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  312.828676] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  312.829255] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.829923] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  312.830501] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  312.831065] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  312.831787] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  312.832450] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  312.833071] rkisp1 ff910000.isp0: capture 0 crop disabled
[  312.833546] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[  312.834006] rkisp1 ff910000.isp0:
[  312.834006]   MIPI_CTRL 0x00061f00
[  312.834006]   MIPI_IMG_DATA_SEL 0x0000002a
[  312.834006]   MIPI_STATUS 0x00002000
[  312.834006]   MIPI_IMSC 0x03f33333
[  312.835559] I'm in rk_dphy_configure
[  312.835887] phy_mipi_dphy_config_validate, ui=250000000000
[  312.836368] phy_mipi_dphy_config_validate, hs_clk_rate=4
[  312.836832] phy_mipi_dphy_config_validate, lp_clk_rate=8192
[  312.837318] phy_mipi_dphy_config_validate, lanes=2
[  312.837738] Invalid clk_post: 3429022304
[  312.838085] ov5647 4-0036: Fail configuring MIPI DPHY
[  312.838529] I'm in rk_dphy_power_on
[  312.841028] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  312.841608] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  312.842280] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  312.842849] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  312.843440] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.844133] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  312.844725] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  312.845496] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  312.846163] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.846835] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  312.847442] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  312.848231] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  312.848841] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  312.849508] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  312.850099] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.850775] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  312.851366] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  312.851964] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  312.852638] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  312.853225] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  312.853802] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  312.854512] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  312.855179] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<MIS=00000000

IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=0000002a
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
# <<<[  313.842400] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  313.842999] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  313.843665] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  313.844256] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  313.844853] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.845526] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  313.846117] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  313.846893] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  313.847562] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.848255] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  313.848863] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  313.849634] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  313.850241] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  313.850908] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  313.851499] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.852191] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  313.852784] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  313.853369] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.854041] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  313.854628] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  313.855205] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  313.855934] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  313.856601] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  313.857887] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  313.858466] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  313.859127] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  313.859691] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  313.860294] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.860964] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  313.861920] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  313.862687] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  313.863349] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.864035] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  313.864637] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  313.865403] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  313.866003] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  313.866664] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  313.867250] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.867933] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  313.868521] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  313.869099] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  313.869767] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  313.870345] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  313.870909] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  313.871616] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  313.872292] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'

However, when I tried to repeat the test, I always got MIPI_STATUS=0x2000
So it ment that both clock and data lanes are in STOP state.
OK. It may have sense, there is a short period in the transmission when they are.
However, why the transmission works with clock line in ULP state?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 5, 2020, 7:54:23 AM2/5/20
to linux-rockchip
Hi,

The ADV7280A-M produces and delivers the MIPI clock. In that situation is the MIPI PLL needed at all?
I thought that it is needed when MIPI is the master of the CSI.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 5, 2020, 1:10:36 PM2/5/20
to linux-rockchip
OK. I was wrong. It looks, like this bit is active low. In a similar chip it is described in that way:

unsigned int ulpsactivenotclk : 1; /* bit[16] : Active Low. Indicates that the lane is in the Ultra Low Power state. For a Tx lane, this signal is asserted some time after TXULPSCLK. TXCLKESC must be supplied to the macro until ULPSACTIVENOTCLK is asserted.
In order to leave ULP state, the transmitter first drives TXULPSEXIT high, then waits for ULPSACTIVENOT to become high (inactive). At that point, the macro is active and has started transmitting a Mark-1 on the Lines. The protocol waits for a time Twakeup and then drives TXULPSCLK inactive to return the Lane to Stop state.
For a Rx lane, this signal indicates that the lane is in ULP state. At the beginning of ULP state, ULPSACTIVENOT is asserted together with RXCLKULPSNOT; at the end of the ULP state, this signal becomes inactive to indicate that the Mark-1 state has been observed. Later, after a period of time Twakeup, the RXULPSCLKNOT signal is deasserted. */

Wojciech Zabolotny

unread,
Feb 5, 2020, 1:31:34 PM2/5/20
to linux-rockchip
Yes, indeed, when I started the acquisition in the background with:
v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1 &

and then kept polling the registers:
 while true; do cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat ; done
I usually get:

MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00060f01
MIPI_IMG_DATA_SEL=0000001e
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00000003

But sometimes:
MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00060f01
MIPI_IMG_DATA_SEL=0000001e
MIPI_STATUS=00002100
ISP_FLAGS_SHD=00000003

So indeed, the data lane 0 is active and sometimes it is in the STOP state.
At least the signal from ADV7280 reaches the DPHY and is correctly interpreted...

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 5, 2020, 1:43:39 PM2/5/20
to linux-rockchip
However, if the image acquisition is running, I should also see sometimes set bits corresponding to HSYNC or VSYNC in the ISP_RIS register.
Instead of this it is always 0...
Wojtek

Wojciech Zabolotny

unread,
Feb 5, 2020, 2:56:00 PM2/5/20
to linux-rockchip
Well, situation is very strange, because I get the same results with disconnected MIPI clock. It looks like the ISP1 driver ignores the incoming clock and generates its own?

Wojtek

Wojciech Zabolotny

unread,
Feb 6, 2020, 6:52:22 PM2/6/20
to linux-rockchip
I thought, that maybe the problem is associated with incorrect virtual channel or data type.
Therefore I have added printing the MIPI_CUR_DATA_ID register.
Unfortunately, it always contains 00000000 . Does it mean, that no data is received at all?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 8, 2020, 2:04:54 PM2/8/20
to linux-rockchip
I have verified, what is the behaviour of ISP1 register in case of successful acquisition.
I have enabled again failed configuration of PHY and performed the tests with OV5647:

++++++++++++++++++++++++++++++++++++++++++++

mount -t debugfs none /sys/kernel/debug

SDDC=/sys/kernel/debug/dynamic_debug/control

for ln in 253 458 ; do echo "file rkisp1-dev.c line $ln +p" > ${SDDC}; done

for ln in 876 501 468  ; do echo "file rkisp1-isp.c line $ln +p" > ${SDDC}; done

for ln in 633 406 408 265 211 226 ; do echo "file rkisp1-resizer.c line $ln +p" > ${SDDC}; done

for ln in 102 114 126 138 304 322 334 342 362 480 494 ; do echo "file mc-entity.c line $ln +p" > ${SDDC}; done


media-ctl -V 1:0[fmt:SBGGR8_1X8/1280x960]


( v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-skip=200 --stream-count=1 & ) ; sleep 1 ; cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat; cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat; cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat ; cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat

++++++++++++++++++++++++++++++++++++++++++++++++++++
Results:

[  641.212133] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  641.212725] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  641.213416] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  641.213986] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  641.214573] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.215241] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  641.267193] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  641.267965] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  641.268628] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.269319] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  641.269920] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  641.270685] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  641.271287] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  641.271949] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  641.272535] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.273217] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  641.273806] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  641.274385] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.275053] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  641.275630] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  641.276195] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  641.276915] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  641.277577] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  641.278198] rkisp1 ff910000.isp0: capture 0 crop disabled
[  641.278674] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[  641.279131] rkisp1 ff910000.isp0:
[  641.279131]   MIPI_CTRL 0x00061f00
[  641.279131]   MIPI_IMG_DATA_SEL 0x0000002a
[  641.279131]   MIPI_STATUS 0x00002000
[  641.279131]   MIPI_IMSC 0x03f33333
[  641.280685] I'm in rk_dphy_configure
[  641.281012] phy_mipi_dphy_config_validate, ui=250000000000
[  641.281494] phy_mipi_dphy_config_validate, hs_clk_rate=4
[  641.281958] phy_mipi_dphy_config_validate, lp_clk_rate=8192
[  641.282445] phy_mipi_dphy_config_validate, lanes=2
[  641.282863] Invalid clk_post: 3429022304
[  641.283211] ov5647 4-0036: Fail configuring MIPI DPHY
[  641.283654] I'm in rk_dphy_power_on
[  641.286163] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  641.286743] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  641.287415] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  641.287984] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  641.288575] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.289269] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  641.289860] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  641.290631] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  641.291296] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.291969] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  641.292575] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  641.293365] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  641.293973] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  641.294641] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  641.295232] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.295909] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  641.296499] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  641.297098] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  641.297773] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  641.298360] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  641.298936] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  641.299646] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  641.300312] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<MIS=00000000

IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=0000002a
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
MIS=00000000
IMSC=0000006a
RIS=0004c080

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=0000002a
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00160003
MIPI_CUR_DATA_ID=0000002a
<MIS=00000000

IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=0000002a
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
MIS=00000000

IMSC=0000006a
RIS=00000080
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000300
MIPI_MIS=00000300
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=0000002a
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00040003
MIPI_CUR_DATA_ID=0000002a

# <<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 53.60 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[  645.086004] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  645.086604] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  645.087271] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  645.087849] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  645.088440] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.089140] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  645.089735] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  645.090511] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  645.091176] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.091854] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  645.092459] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  645.093243] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  645.093857] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  645.094524] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  645.095115] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.095792] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  645.096383] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  645.096986] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.097660] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  645.098243] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  645.098812] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  645.099525] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  645.100190] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  645.101487] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  645.102067] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  645.102727] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  645.103291] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  645.103875] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.104544] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  645.105518] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  645.106286] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  645.106947] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.107615] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  645.108215] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  645.109001] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  645.109603] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  645.110264] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  645.110850] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.111518] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  645.112104] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  645.112682] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  645.113362] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  645.113942] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  645.114506] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  645.115212] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  645.115873] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'

It can be seen, that the ISP_FLAGS_SHD indeed contains changing contents of bits 23-16 (where it should present the bits received from PHY).
And MIPI_IMG_DATA_SEL shows that it receives the data of type 0x2A - RAW 8 bit.
In the MIPI_MIS it happened that it was set to 0x00000300 - RKISP1_CIF_MIPI_ERR_SOT_SYNC  for lanes 0 and 1 (used by OV5647).
In the MIPI_RIS it happened that it contained 0x00000080 - RKISP1_CIF_ISP_H_START

None of those bits got ever set in case of acquisition from ADV7280, so it seems that the acquisition is really stalled...

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 8, 2020, 2:21:30 PM2/8/20
to linux-rockchip
For RK3288 I have found in the Internet very nice documentation:
rk3288-chapter-36-mipi-csi-2-host-controller.pdf
rk3288-chapter-35-mipi-csi-phy.pdf

Is the similar documentation also available fopr RK3399?

Especially I would be interested in registers similar to CSIHOST_ERR1 and CSIHOST_ERR2 in RK3288.

Regards,
Wojek

Wojciech Zabolotny

unread,
Feb 8, 2020, 3:14:29 PM2/8/20
to linux-rockchip
I have made an experiment checking if the problem is related to improper selection of CSI data type for ADV7280.
Therefore I have changed the definition for the format used by OV5647:

With such modified kernel, I have tried to start the acquisition.
At first glance it seemed that I have recreated the problem with ADV7280 - the acquisition stalled.
However, when I started to dump the registers, I could see a significant difference:

The data were flowing to the ISP, and MIPI reported the correct data type:

# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-skip=50 --stream-count=1 &
# [  387.563136] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  387.563729] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  387.564427] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  387.564996] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  387.565582] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.566251] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  387.622583] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  387.623354] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  387.624014] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.624704] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  387.625305] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  387.626072] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  387.626673] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  387.627335] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  387.627921] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.628601] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  387.629190] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  387.629768] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.630436] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  387.631014] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  387.631577] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  387.632299] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  387.632961] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'
[  387.633582] rkisp1 ff910000.isp0: capture 0 crop disabled
[  387.634092] I'm in rk_dphy_configure
[  387.634406] phy_mipi_dphy_config_validate, ui=250000000000
[  387.634884] phy_mipi_dphy_config_validate, hs_clk_rate=4
[  387.635348] phy_mipi_dphy_config_validate, lp_clk_rate=72340172838076673
[  387.635932] phy_mipi_dphy_config_validate, lanes=2
[  387.636364] Invalid clk_post: 3429022304
[  387.636714] ov5647 4-0036: Fail configuring MIPI DPHY
[  387.637156] I'm in rk_dphy_power_on
[  387.639645] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'
[  387.640245] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack
[  387.640907] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_isp' on stack
[  387.641470] rkisp1 ff910000.isp0: walk: pushing 'ov5647 4-0036' on stack
[  387.642055] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.642723] rkisp1 ff910000.isp0: walk: returning entity 'ov5647 4-0036'
[  387.643309] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_mainpath' (already seen)
[  387.644075] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_selfpath' on stack
[  387.644753] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.645423] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_selfpath' on stack
[  387.646024] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_resizer_selfpath' (already seen)
[  387.646790] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_selfpath'
[  387.647394] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_selfpath'
[  387.648057] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_params' on stack
[  387.648655] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.649325] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_params'
[  387.649912] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_stats' on stack
[  387.650490] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_isp' (already seen)
[  387.651158] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_stats'
[  387.651736] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_isp'
[  387.652313] rkisp1 ff910000.isp0: walk: skipping entity 'rkisp1_mainpath' (already seen)
[  387.653021] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_resizer_mainpath'
[  387.653683] rkisp1 ff910000.isp0: walk: returning entity 'rkisp1_mainpath'

#
# /sys/class/video4linux/v4l-subdev0/device/isp1_stat; cat
-sh: /sys/class/video4linux/v4l-subdev0/device/isp1_stat: Permission denied
^[[A^C
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00030003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00070003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00030003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000b0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000e0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000b0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00040003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00030003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00030003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000c0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00050003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00130003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000d0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000300
MIPI_MIS=00000300
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00030003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00050003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000300
MIPI_MIS=00000300
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00040003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00050003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00050003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000300
MIPI_MIS=00000300
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00060003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=000f0003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00160003
MIPI_CUR_DATA_ID=0000002a
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002300
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=00000001
# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat
MIS=00000000
IMSC=0000006a
RIS=00000000

ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000097
ACQ_PROP=00000018
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f33333
MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00061f01
MIPI_IMG_DATA_SEL=00000022
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00200003
MIPI_CUR_DATA_ID=0000002a
# 


So the question is - what causes that in case of ADV7280 data do not flow at all?
The main difference is that ADV7280 uses only a single lane.
Maybe the driver does not set certain option required for such configuration?
The another difference, that for OV5647 the PHY is not reconfigured (as checking the
validity of the configuration fails).
What is the difference between the initial configuration of PHY and the one set by the driver?

--
Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 8, 2020, 3:58:11 PM2/8/20
to linux-rockchip
To find out what is the difference between the OV5647 and ADV7280, I have taken a look at signals on the CSI bus.
That's what I have seen for OV5647:


That's what I have seen for ADV7280 in three different time scales (to show details):

It looks, like the organization of the data on the CSI bus in case of ADV7280A-M is much more complex, than in case of OV5647.
Maybe it requires setting certain additional options in MIPI PHY to have them recognized?

With best regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 8, 2020, 7:33:50 PM2/8/20
to linux-rockchip
Is it possible that ISP1 does not recognize HS due to the fact that short packets are sent?

Regards, 
Wojtek

--
You received this message because you are subscribed to the Google Groups "linux-rockchip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-rockchi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linux-rockchip/77340b23-a150-4289-807f-67898934b50f%40googlegroups.com.

Wojciech Zabolotny

unread,
Feb 9, 2020, 2:11:34 PM2/9/20
to linux-rockchip
OK. I have one important finding. With all my debugging on, I get the following for ADV7280:

[  774.268026] rkisp1 ff910000.isp0:
[  774.268026]   MIPI_CTRL 0x00060f00
[  774.268026]   MIPI_IMG_DATA_SEL 0x0000001e
[  774.268026]   MIPI_STATUS 0x00002000
[  774.268026]   MIPI_IMSC 0x03f33333
[  774.271924] I'm in rk_dphy_configure
[  774.273766] phy_mipi_dphy_config_validate, ui=4630
[  774.274836] phy_mipi_dphy_config_validate, hs_clk_rate=216000000
[  774.276043] phy_mipi_dphy_config_validate, lp_clk_rate=8192
[  774.278039] phy_mipi_dphy_config_validate, lanes=1
[  774.279412] rockchip-mipi-dphy-rx0 ff770000.syscon:mipi-dphy-rx0: lanes 1 - data_rate_mbps 216
[  774.281887] I'm in rk_dphy_power_on

In fact for ADV7280 in progressive mode, I should get:
ui=2310
not ui=4630 (which is correct for the interlaced mode).
If that value affects limits for detection of synchronization markers, it may explain the stall
(as no synchronization is ever found).

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 9, 2020, 2:17:29 PM2/9/20
to linux-rockchip
In rksip1-isp.c, phy_mipi_dphy_get_default_config is called as

       phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
                                         sensor->lanes, cfg);

of course bus_width is set to 8

However in phy_mipi_dphy_get_default_config the second parameter is interpreted as "bpp" (bits per pixel).
So it should be 16!

Can it be the cause of the troubles?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 11, 2020, 4:19:31 PM2/11/20
to linux-rockchip
I have tried to sort out the things related to hs_clk_rate ans hs_data_rate.
It seems that whats needed in the PHY configuration routine is the data rate.
At least that's what the TRM says in Part2.
Table 7-2 defines values in Mbps so probably it is the bitrate not the
hs clock frequency.
Therefore,  to avoid the tricks that I have introduced in commits:
https://github.com/torvalds/linux/commit/2c7912e1b8cdfe2b94ac03f8f70bbd2b97aad864
and
https://github.com/torvalds/linux/commit/981208605ed00d76a7c9e6cad30b6ac41259fab1
I need to change the bus_width definition from 8 bits to 16 bits:
https://github.com/torvalds/linux/commit/26849f392e644e9312a644879a6d03d307885b30
then the "ui" and hsfreqrange are calculated correctly:

[ 1588.197137] rkisp1 ff910000.isp0: CIF_ID 0x10853017
[ 1588.197595] rkisp1 ff910000.isp0:
[ 1588.197595]   MIPI_CTRL 0x00060f00
[ 1588.197595]   MIPI_IMG_DATA_SEL 0x0000001e
[ 1588.197595]   MIPI_STATUS 0x00002000
[ 1588.197595]   MIPI_IMSC 0x03f33333
[ 1588.199165] I'm in rk_dphy_configure
[ 1588.199481] phy_mipi_dphy_config_validate, ui=2315
[ 1588.199901] phy_mipi_dphy_config_validate, hs_clk_rate=432000000
[ 1588.200425] phy_mipi_dphy_config_validate, lp_clk_rate=8192
[ 1588.200911] phy_mipi_dphy_config_validate, lanes=1
[ 1588.201336] rockchip-mipi-dphy-rx0 ff770000.syscon:mipi-dphy-rx0:
lanes 1 - data_rate_mbps 432
[ 1588.202086] I'm in rk_dphy_power_on

Unfortunately the data acquisition still stalls.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 12, 2020, 3:50:21 AM2/12/20
to linux-rockchip
I have found an interesting thing in rkisp1-regs.h:

#define RKISP1_CIF_MIPI_ERR_DPHY  (RKISP1_CIF_MIPI_ERR_SOT(3) | \
        RKISP1_CIF_MIPI_ERR_SOT_SYNC(3) | \
        RKISP1_CIF_MIPI_ERR_EOT_SYNC(3) | \
        RKISP1_CIF_MIPI_ERR_CTRL(3))

If the above bitmasks are defined "per lane", it means that this driver has hardcoded using two lanes.
Can it be a reason why it doesn't work with ADV7280 which uses only a single lane?
Are there other places where two-lane operation is hardcoded?

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 12, 2020, 10:59:53 AM2/12/20
to linux-rockchip
I have introduced the modifications that change the hard-coded two-lane operation into hard-coded one-lane operation.
(Of course it would break OV5647, but should  enable ADV7280).

Unfortunately, the acquisition of data from ADV7280 still does not work.
This is the dump of registers during the stalled acquisition:

# cat /sys/class/video4linux/v4l-subdev0/device/isp1_stat

MIS=00000000
IMSC=0000006e
RIS=00000000
ICR=00000000
ISR=00000000
ERR=00000000
CTRL=00000095
ACQ_PROP=00000100
MI_CTRL=00ba2001
MI_BYTE_CNT=00000000
MIPI_IMSC=03f11111

MIPI_RIS=00000000
MIPI_MIS=00000000
MIPI_ICR=00000000
MIPI_ISR=00000000
MIPI_CTRL=00060f01
MIPI_IMG_DATA_SEL=0000001e
MIPI_STATUS=00002000
ISP_FLAGS_SHD=00000003
MIPI_CUR_DATA_ID=00000000

From time to time I get
MIPI_STATUS=00002100


Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 12, 2020, 1:17:46 PM2/12/20
to linux-rockchip
I have reeanbled the code that tries to selectively enable the DATA lanes in MIPI:
And then checked the hypothesis that the order of bits is reversed:

In both cases I have stopped receiving MIPI_STATUS=00002100
So probably RKISP1_CIF_MIPI_CTRL_SHUTDOWNLANES must be set to 0xf
I have restored it in

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 13, 2020, 6:49:37 PM2/13/20
to linux-rockchip
Comparing the old driver (rk_isp10) with the new one, I have found an interesting difference.
In the old driver, there is the whole procedure that sets the TXRX1 PHY in the slave mode:
https://github.com/rockchip-linux/kernel/blob/73795337dde7cbc27735ff2f7e9fb328963eb2bd/drivers/media/platform/rk-isp10/cif_isp10_rk3399.c#L301
even though input 0 is used.
There is no such operation in the new driver.
https://github.com/wzab/linux/blob/d5a704062fef2fed5bc672018474ac8fb042908e/drivers/staging/media/phy-rockchip-dphy-rx0/phy-rockchip-dphy-rx0.c#L188
Is it possible that this leaves the PHY in the master mode and causes
it to ignore the received clock?

Regards,
Wojtek


Wojciech Zabolotny

unread,
Feb 16, 2020, 5:07:38 PM2/16/20
to linux-rockchip
I have performed a few more experiments, trying to get the data transmitted through the D-PHY.
Generally, I tried to imitate the PHY initalization routine from the old driver.
Up know I have achieved no success.
What is still lacking, is reading the last programmed register (as there is no rk_dphy_read function).

Maybe it is necessary to set the SHUTDOWNZ and RSTZ controls in the DSIHOST section?


Regards,
Wojtek


Wojciech Zabolotny

unread,
Feb 17, 2020, 6:14:39 PM2/17/20
to linux-rockchip
In one of the previous posts I have reported a problem with phy_mipi_dphy_config_validate failing for OV5647.
It seems, that the problem is related to improper initialization of the pixel rate control.
After the start of the system it has an icorrect value:

# v4l2-ctl --all -d /dev/v4l-subdev3

Image Processing Controls

                     pixel_rate 0x009f0902 (int64)  : min=1 max=2147483647 step=1 default=1 value=1 flags=read-only

However if I try to set another format:

# media-ctl -V 28:0[fmt:SBGGR8_1X8/1024x768]
[  758.263414] new mode is 1280x960
[  758.263707] pixel rate is now 83954880

It gets correctly set:
# v4l2-ctl --all -d /dev/v4l-subdev3

Image Processing Controls

                     pixel_rate 0x009f0902 (int64)  : min=1 max=2147483647 step=1 default=1 value=83954880 flags=read-only

And further  attempt to start streaming does not report failed validation of the phy configuration:

# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-skip=50 --stream-count=1
[  763.153646] I'm in rk_dphy_configure
[  763.153971] phy_mipi_dphy_config_validate, ui=2978
[  763.154390] phy_mipi_dphy_config_validate, hs_clk_rate=335819520
[  763.154914] phy_mipi_dphy_config_validate, lp_clk_rate=72340172838076673
[  763.155521] phy_mipi_dphy_config_validate, lanes=2
[  763.155944] I'm in rk_dphy_power_on
[  763.156259] Calling rk_dphy_enable.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Regards,
Wojtek
# media-ctl -V 28:0[fmt:SBGGR8_1X8/1024x768]
[  758.263414] new mode is 1280x960
[  758.263707] pixel rate is now 83954880

# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-ski
p=50 --stream-count=1
[  763.153646] I'm in rk_dphy_configure
[  763.153971] phy_mipi_dphy_config_validate, ui=2978
[  763.154390] phy_mipi_dphy_config_validate, hs_clk_rate=335819520
[  763.154914] phy_mipi_dphy_config_validate, lp_clk_rate=72340172838076673
[  763.155521] phy_mipi_dphy_config_validate, lanes=2
[  763.155944] I'm in rk_dphy_power_on
[  763.156259] Calling rk_dphy_enable.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Wojciech Zabolotny

unread,
Feb 18, 2020, 3:33:18 PM2/18/20
to linux-rockchip
I have checked yet another hypothesis that the pixel rate should in fact be a "sample rate", so it should be set for 54 MHz for ADV7280A-M in the progressive mode, while bpp for the format should be set for 8.
That setting results in HS clk frequency of 216 MHz (data rate 432  Mbps), but the bus width is set to 8 (as it in fact should be).
Unfortunately, that modification: https://github.com/wzab/linux/commit/e5c7542c39dfc30051f6f5c9bead8411c9e1a12e also didn't solve the problem. The PHY still does not transfer any data.
I can only see that MIPI_STATUS sometimes has the value 0x00002100 (so PHY sees the activity on the data lane, but no data is received).
As I have shown previously, the configuration for OV5647 works. So there are three things, that are different for OV5647 and ADV7280:
  1. OV5647 uses two lanes, while ADV7280A-M uses only one lane. Is there any additional setting that must be changed to inform PHY or ISP1 that it should receive data from one lane only?
  2. OV5647 uses the c.a. 336Mbps data rate, while ADV uses 432Mbps data lane. Is there any additional modification needed except of changing the hsfreqrange value?
  3. ADV sends short packet at the begining of the line. OV doesn't. Is there any special setting that must be selected in ISP1 to enable correct reception of the video stream with short packets?
Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 24, 2020, 5:56:34 PM2/24/20
to linux-rockchip
In the meantime I had to try to connect TC358743 to RK3399. It allowed me to find the reason of certain problems related to the ADV7280.
For example, it seems stall in the data transfer may be caused by improper setting of hsfreqrange.

The kernel with somehow working TC358743 driver is available in the commit https://github.com/wzab/linux/commit/d5cd92a4b171808792110e9cf7a0b4c56df60d6d

To start grabbing of 1920x1080@30 video I had to use the 1080P30EDID.txt file:

00ffffffffffff005262888800888888
1c150103800000780aEE91A3544C9926
0F505400000001010101010101010101
010101010101011d007251d01e206e28
5500c48e2100001e8c0ad08a20e02d10
103e9600138e2100001e000000fc0054
6f73686962612d4832430a20000000FD
003b3d0f2e0f1e0a2020202020200100
020321434e041303021211012021a23c
3d3e1f2309070766030c00300080E300
7F8c0ad08a20e02d10103e9600c48e21
0000188c0ad08a20e02d10103e960013
8e210000188c0aa01451f01600267c43
00138e21000098000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

And configure streaming as below:

v4l2-ctl -d /dev/v4l-subdev3 --set-edid=file=/opt/1080P30EDID.txt --fix-edid-checksums
v4l2-ctl -d /dev/v4l-subdev3 --set-dv-bt-timings index=10
media-ctl -r
media-ctl -l "28:0->1:0[1]"
media-ctl -l "1:2->6:0[1]"
media-ctl -l "6:1->12:0[1]"
media-ctl -V 28:0[fmt:UYVY/1920x1080]
media-ctl -V 1:0[fmt:UYVY8_1X16/1920x1080]
media-ctl -V "1:0[crop:(0,0)/1920x1080]"
media-ctl -V 1:2[fmt:UYVY8_1X16/1920x1080]
media-ctl -V "1:2[crop:(0,0)/1920x1080]"
media-ctl -V 6:0[fmt:YUYV8_2X8/1920x1080]
media-ctl -V "6:0[crop:(0,0)/1920x1080]"
media-ctl -V 6:1[fmt:JPEG_1X8/800x600]

v4l2-ctl --device /dev/video0 --set-fmt-video=width=800,height=600,pixelformat=YUYV
DEVICE=/dev/video0
SERVER=172.19.1.1
PORT=5000
gst-launch-1.0 v4l2src device=$DEVICE !  'video/x-raw,format=YUY2,width=800,height=600,framerate=30/1' ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT

To start grabbing of 1024x768@60 video I had to use the 768P60EDID.txt file:

00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00
05 16 01 03 6d 23 1a 78 ea 5e c0 a4 59 4a 98 25
20 50 54 00 08 00 61 40 01 01 01 01 01 01 01 01
01 01 01 01 01 01 64 19 00 40 41 00 26 30 08 90
36 00 63 0a 11 00 00 18 00 00 00 ff 00 4c 69 6e
75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b
3d 2f 31 07 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 69 6e 75 78 20 58 47 41 0a 20 20 20 00 55

And configure the streaming as below:
v4l2-ctl -d /dev/v4l-subdev3 --set-edid=file=/opt/768P60EDID.txt --fix-edid-checksums
v4l2-ctl -d /dev/v4l-subdev3 --set-dv-bt-timings index=26
media-ctl -r
media-ctl -l "28:0->1:0[1]"
media-ctl -l "1:2->6:0[1]"
media-ctl -l "6:1->12:0[1]"
media-ctl -V 28:0[fmt:UYVY8_1x16/1024x768]
media-ctl -V 1:0[fmt:UYVY8_1X16/1024x768]
media-ctl -V "1:0[crop:(0,0)/1024x768"
media-ctl -V 1:2[fmt:UYVY8_1X16/1024x768]
media-ctl -V "1:2[crop:(0,0)/1024x768]"
media-ctl -V 6:0[fmt:YUYV8_2X8/1024x768]
media-ctl -V "6:0[crop:(0,0)/1024x768]"
media-ctl -V 6:1[fmt:JPEG_1X8/800x600]

v4l2-ctl --device /dev/video0 --set-fmt-video=width=800,height=600,pixelformat=YUYV
DEVICE=/dev/video0
SERVER=172.19.1.1
PORT=5000
gst-launch-1.0 v4l2src device=$DEVICE !  'video/x-raw,format=YUY2,width=800,height=600,framerate=30/1' ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT

In both cases the reception on the PC (172.19.1.1) was started with:
gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 ! rtpjpegdepay ! jpegdec ! autovideosink

With best regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 24, 2020, 5:58:29 PM2/24/20
to linux-rockchip
Of course in the procedure starting grabbing of 1024x768@60 there is a mistake.
There should be:
media-ctl -V "1:0[crop:(0,0)/1024x768]"
not
media-ctl -V "1:0[crop:(0,0)/1024x768"

Wojciech Zabolotny

unread,
Feb 24, 2020, 6:08:50 PM2/24/20
to linux-rockchip
The device tree overlay used with TC358743 is the following:

/dts-v1/;
/plugin/;


/ {
        model = "ROCK PI 4B";
        compatible = "rockchip,rockpi","rockchip,rk3399";
       
    fragment@0 {
        target = <&rpicamv1>;
        __overlay__ {
            status = "disabled";
        };
    };

    fragment@1 {
        target = <&i2c4>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            tc358743@f {
                compatible = "toshiba,tc358743";
                reg = <0x0f>;
                status = "okay";

                                clocks = <&tc358743_clk>;
                                clock-names = "refclk";

                               tc358743_clk: bridge-clk {
                                        compatible = "fixed-clock";
                                        #clock-cells = <0>;
                                        clock-frequency = <27000000>;
                                };
  
                port {
                    tc358743: endpoint {
                        remote-endpoint = <&csi1_ep1>;
                        clock-lanes = <0>;
                        data-lanes = <1 2>;
                        link-frequencies = /bits/ 64 <297000000>;
                    };
                };
            };
        };
    };

        fragment@2 {
                target = <&csi1_ep1>;
                __overlay__ {
                                    remote-endpoint = <&tc358743>;
                        };
        };
};

Wojciech Zabolotny

unread,
Feb 24, 2020, 6:22:06 PM2/24/20
to linux-rockchip
The procedure for starting the streaming of 1024x768@60 should be also slightly modified:
(there was an erroneous command: media-ctl -V "1:0[crop:(0,0)/1024x768"
and the framerate was set to 30fps instead of 60fps)

v4l2-ctl -d /dev/v4l-subdev3 --set-edid=file=/opt/768P60EDID.txt --fix-edid-checksums
v4l2-ctl -d /dev/v4l-subdev3 --set-dv-bt-timings index=26
media-ctl -r
media-ctl -l "28:0->1:0[1]"
media-ctl -l "1:2->6:0[1]"
media-ctl -l "6:1->12:0[1]"
media-ctl -V 28:0[fmt:UYVY/1024x768]

media-ctl -V 1:0[fmt:UYVY8_1X16/1024x768]
media-ctl -V "1:0[crop:(0,0)/1024x768]"
media-ctl -V 1:2[fmt:UYVY8_1X16/1024x768]
media-ctl -V "1:2[crop:(0,0)/1024x768]"
media-ctl -V 6:0[fmt:YUYV8_2X8/1024x768]
media-ctl -V "6:0[crop:(0,0)/1024x768]"
media-ctl -V 6:1[fmt:JPEG_1X8/800x600]

v4l2-ctl --device /dev/video0 --set-fmt-video=width=800,height=600,pixelformat=YUYV
DEVICE=/dev/video0
SERVER=172.19.1.1
PORT=5000
gst-launch-1.0 v4l2src device=$DEVICE !  'video/x-raw,format=YUY2,width=800,height=600,framerate=60/1' ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT

Wojciech Zabolotny

unread,
Feb 24, 2020, 7:37:10 PM2/24/20
to linux-rockchip
Now I would like to get the ADV7280A-M working with RK3399.
As found with TC358743, one reason for stalling the data transfer may be incorrect setting of hsfreqrange parameter.
However,I have checked once again. The hsfreqrange for ADV7280A-M is set correctly.

So the only significant differences between OV5647, TC358743 and ADV7280A-M are:

1. The number of data lanes (TC358743 and OV5647 use 2 lanes in my setup (in certain cases TC may use even 4), while ADV7280A-M uses one)
2. Maybe the usage of short packets between lines (ADV uses them, OV does not use, TC also does not use, as it can be clearly seen from the pictures below)


Now I need to force TC358743 to send data via a single lane, e.g. by grabbing 1024x76x@30 video...

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 24, 2020, 8:12:43 PM2/24/20
to linux-rockchip
I have tried to grab the 800x600@60 video, that also fits in a single lane.

The EDID file: 600P60EDIT.txt

00ffffffffffff0031d8000000000000

051601036d1b1478ea5ec0a4594a9825

20505401000045400101010101010101

010101010101a00f200031581c202880

140015d01000001e000000ff004c696e

75782023300a20202020000000fd003b

3d242605000a202020202020000000fc

004c696e757820535647410a202000c2


The start procedure:


v4l2-ctl -d /dev/v4l-subdev3 --set-edid=file=/opt/600P60EDID.txt --fix-edid-checksums

v4l2-ctl -d /dev/v4l-subdev3 --set-dv-bt-timings index=20

media-ctl -r

media-ctl -l "28:0->1:0[1]"

media-ctl -l "1:2->6:0[1]"

media-ctl -l "6:1->12:0[1]"

media-ctl -V 28:0[fmt:UYVY/800x600]

media-ctl -V 1:0[fmt:UYVY8_1X16/800x600]

media-ctl -V "1:0[crop:(0,0)/800x600]"

media-ctl -V 1:2[fmt:UYVY8_1X16/800x600]

media-ctl -V "1:2[crop:(0,0)/800x600]"

media-ctl -V 6:0[fmt:YUYV8_2X8/800x600]

media-ctl -V "6:0[crop:(0,0)/800x600]"

media-ctl -V 6:1[fmt:JPEG_1X8/800x600]


v4l2-ctl --device /dev/video0 --set-fmt-video=width=800,height=600,pixelformat=YUYV


DEVICE=/dev/video0
SERVER=172.19.1.1
PORT=5000
gst-launch-1.0 v4l2src device=$DEVICE !  'video/x-raw,format=YUY2,

width=800,height=600,framerate=60/1' ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT

Unfortunately, it appeared that even though the format is recognized as using a single lane:


# media-ctl -V 28:0[fmt:UYVY/800x600]

[ 3115.974685] Number of lanes in set_fmt: 1


Later on the usage of two lanes is enforced:


 

[ 3182.170495] rkisp1 ff910000.isp0: capture 0 crop disabled

[ 3182.170971] rkisp1 ff910000.isp0: CIF_ID 0x10853017

[ 3182.171429] rkisp1 ff910000.isp0:

[ 3182.171429]   MIPI_CTRL 0x00061f00

[ 3182.171429]   MIPI_IMG_DATA_SEL 0x0000001e

[ 3182.171429]   MIPI_STATUS 0x00002000

[ 3182.171429]   MIPI_IMSC 0x03f33333

[ 3182.172983] I'm in rk_dphy_configure

[ 3182.173296] phy_mipi_dphy_config_validate, ui=3367

[ 3182.173716] phy_mipi_dphy_config_validate, hs_clk_rate=297000000

[ 3182.174257] phy_mipi_dphy_config_validate, lp_clk_rate=8192

[ 3182.174745] phy_mipi_dphy_config_validate, lanes=2

[ 3182.175171] rockchip-mipi-dphy-rx0 ff770000.syscon:mipi-dphy-rx0: lanes 2 - data_rate_mbps 297

[ 3182.175921] I'm in rk_dphy_power_on

[ 3182.176235] Calling rk_dphy_enable.

[ 3182.178927] rkisp1 ff910000.isp0: begin graph walk at 'rkisp1_mainpath'

[ 3182.179507] rkisp1 ff910000.isp0: walk: pushing 'rkisp1_resizer_mainpath' on stack


I have tried to limit the number of data-lanes in the device tree, but the result is the same.


So at the moment I can not check if the problem with ADV7280 is caused by the number of data lanes equal to 1, or by using the short packets.


Regards,

Wojtek

Wojciech Zabolotny

unread,
Feb 25, 2020, 9:09:11 AM2/25/20
to linux-rockchip
I have just discovered that phy_mipi_dphy_get_default_config is very rarely used in the mainline kernel:

Both uses are for DSI, not for CSI:

https://elixir.bootlin.com/linux/v5.5.6/source/drivers/gpu/drm/bridge/cdns-dsi.c#L618
https://elixir.bootlin.com/linux/v5.5.6/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L744

The question is if that function is granted to work correctly for the receiver?
Maybe it does not set the timing correctly for reception of short packets send between the LP pulses between the lines of the image?

With best regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 25, 2020, 1:21:08 PM2/25/20
to linux-rockchip
I have managed to get streaming from TC358743 via a single lane.
The configuration is as follows:

file /opt/600P60EDID.txt
00ffffffffffff0031d8000000000000
051601036d1b1478ea5ec0a4594a9825
20505401000045400101010101010101
010101010101a00f200031581c202880
140015d01000001e000000ff004c696e
75782023300a20202020000000fd003b
3d242605000a202020202020000000fc
004c696e757820535647410a202000c2

Device Tree Overlay:
                        data-lanes = <1>;

                        link-frequencies = /bits/ 64 <297000000>;
                    };
                };
            };
        };
    };

        fragment@2 {
                target = <&csi1_ep1>;
                __overlay__ {
                                remote-endpoint = <&tc358743>;
                data-lanes = <1>;
                        };
        };
};
please note that I had toi limit the number of data lanes in the receiving endpoint to 1. Otherwise two-lane configuration was selected as described in the post https://groups.google.com/d/msg/linux-rockchip/qnX2QlaLM3A/7YtsQ9UpAgAJ

The start procedure:

v4l2-ctl -d /dev/v4l-subdev3 --set-dv-bt-timings index=20

media-ctl -r

media-ctl -l "28:0->1:0[1]"

media-ctl -l "1:2->6:0[1]"

media-ctl -l "6:1->12:0[1]"

media-ctl -V 28:0[fmt:UYVY/800x600]

media-ctl -V 1:0[fmt:UYVY8_1X16/800x600]

media-ctl -V "1:0[crop:(0,0)/800x600]"

media-ctl -V 1:2[fmt:UYVY8_1X16/800x600]

media-ctl -V "1:2[crop:(0,0)/800x600]"

media-ctl -V 6:0[fmt:YUYV8_2X8/800x600]

media-ctl -V "6:0[crop:(0,0)/800x600]"

media-ctl -V 6:1[fmt:JPEG_1X8/800x600]


v4l2-ctl --device /dev/video0 --set-fmt-video=width=800,height=600,pixelformat=YUYV

DEVICE=/dev/video0
SERVER=172.19.1.1
PORT=5000
gst-launch-1.0 v4l2src device=$DEVICE !  'video/x-raw,format=YUY2,
width=800,height=600,framerate=60/1' ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT

Reception in the PC was started with:
gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 ! rtpjpegdepay ! jpegdec ! autovideosink

So it seems that transmission via a single lane works correctly.
(Well, maybe I should also test a paranoic hypothesis that the 2nd lane is still connected and that's why it works with TC358743, and doesn't work with ADV7280. Unfortunately, I do not have a flat ribbon to destroy to check if a single-lane configuration with TC358743 works even when the 2nd lane is cut.)

So it seems, that there is only one reason why ADV7280A-M does not work. Thats sending of short packets at the begining og the image line between two LP pulses.
See waveform for ADV7280A-M:
And the image for TC358743 with single-lane transmission of 800x600@60

So now the question is: How to enable PHY in RK3399 to receive such signal, or how to force ADV7280A-M to send video in the format similar to the one used by TC358743 or OV5647...

With best regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 25, 2020, 5:32:24 PM2/25/20
to linux-rockchip
I have recalculated the timing once again. The transmission of a single image line is shown here:
So it means that ADV7280A-M sends:
  1. Start of the line short packet
  2. Line data
  3. End of the line short packet
  4. Certain additional information sent during the horizontal blanking interval
It seems that this information is not accepted either by PHY or by ISP in RK3399.

Regards,
Wojtek

Wojciech Zabolotny

unread,
Feb 25, 2020, 7:34:38 PM2/25/20
to linux-rockchip
I have checked once again that the waveform on the data lane is the same when ADV7280A-M successfully transmits data to the Raspberry PI B+.
So it is obviously not a problem with ADV7280A-M or its driver, but with configuration of either PHY or ISP in RK3399.

Regards,
Wojtek

wza...@gmail.com

unread,
Jan 22, 2021, 7:21:38 AM1/22/21
to linux-rockchip
I had to return to the problem of the ADV7280A-M connection to the RK3399.
Now I had to use the standard 4.4 BSP kernel, which was somehow improved since February 2020, that I described earlier in that thread.
Unfortunately, the situation looks the same as previously - the RKISP1 and ADV7280A-M get configured, but then RKISP1 does not recognize the data.
It seems that the problem is still associated with short packets sent between the LP pulses.
(Quoting my previous message:
See waveform for ADV7280A-M (unsuccessful transmission):
And the image for TC358743 with single-lane transmission of 800x600@60 (successful transmission)
)
Has anybody succeeded to connect ADV7280A-M or another sensor/converter using short packets to RKISP1?

Thank you very much in advance,
With best regards,
Wojtek
Reply all
Reply to author
Forward
0 new messages