Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0 #314

Open
floydelcy opened this issue Jan 21, 2024 · 1 comment
Open

rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0 #314

floydelcy opened this issue Jan 21, 2024 · 1 comment

Comments

@floydelcy
Copy link

RK3566 (orangepi CM4) TC358743做hdmiin

数据链路：TC358743->csi2_dphy1->MIPI_CSI2->RKCIF_MIPI_LVDS

  • 使用v4l2-ctl抓图，图像杂乱,dmesg报错，rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
image 
root@orangepicm4:~# v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat='NV12' --stream-mmap=4 --stream-skip=3 --stream-to=2k_nv12.yuv --stream-count=4 --stream-poll
VIDIOC_QUERYCAP: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture Multiplanar:
	Width/Height      : 1920/1080
	Pixel Format      : 'NV12' (Y/CbCr 4:2:0)
	Field             : None
	Number of planes  : 1
	Flags             : 
	Colorspace        : Default
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Default
	Plane 0           :
	   Bytes per Line : 1920
	   Size Image     : 3110400
		VIDIOC_REQBUFS returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq:      2 bytesused: 3110400 ts: 1206.852213 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      4 bytesused: 3110400 ts: 1206.885563 delta: 33.350 ms dropped: 1 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      6 bytesused: 3110400 ts: 1206.918846 delta: 33.283 ms dropped: 1 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      7 bytesused: 3110400 ts: 1206.935536 delta: 16.690 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      9 bytesused: 3110400 ts: 1206.968942 delta: 33.406 ms fps: 59.97 dropped: 1 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:     11 bytesused: 3110400 ts: 1207.002239 delta: 33.297 ms fps: 59.99 dropped: 1 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:     13 bytesused: 3110400 ts: 1207.035635 delta: 33.396 ms fps: 59.97 dropped: 1 (ts-monotonic, ts-src-eof)

***Dmesg***
[ 1212.658024] stream_cif_mipi_id0: open video, entity use_countt 1
[ 1212.737491] rkcif_mipi_lvds: stream[0] start streaming
[ 1212.743136] rkcif_mipi_lvds: Allocate dummy buffer, size: 0x003f5000
[ 1212.743461] rockchip-mipi-csi2 fdfb0000.mipi-csi2: stream on, src_sd: 000000001354f0c4, sd_name:rockchip-csi2-dphy1
[ 1212.743490] rockchip-mipi-csi2 fdfb0000.mipi-csi2: stream ON
[ 1212.743583] rockchip-csi2-dphy1: dphy1, data_rate_mbps 620
[ 1212.743651] rockchip-csi2-dphy csi2-dphy1: csi2_dphy_s_stream stream on:1, dphy1
[ 1212.743678] rockchip-csi2-dphy csi2-dphy1: csi2_dphy_s_stream stream on:1, dphy1
[ 1212.778839] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.809018] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.838327] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.898019] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.928171] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.958325] rkcif_mipi_lvds: ERR: multi fs in oneframe in id0, fs_num:0
[ 1212.975908] rkcif_mipi_lvds: stream[0] start stopping, total mode 0x1, cur 0x1
[ 1212.975922] rkcif_mipi_lvds: get vblank fail, vblank_def 0, vblank_curr 0
[ 1212.988383] rockchip-mipi-csi2 fdfb0000.mipi-csi2: stream off, src_sd: 000000001354f0c4, sd_name:rockchip-csi2-dphy1
[ 1212.988394] rockchip-mipi-csi2 fdfb0000.mipi-csi2: stream OFF
[ 1212.989112] rockchip-csi2-dphy csi2-dphy1: csi2_dphy_s_stream_stop stream stop, dphy1
[ 1212.989127] rockchip-csi2-dphy csi2-dphy1: csi2_dphy_s_stream stream on:0, dphy1
[ 1212.989159] rockchip-csi2-dphy csi2-dphy1: csi2_dphy_s_stream stream on:0, dphy1
[ 1213.008111] rkcif_mipi_lvds: stream[0] stopping finished, dma_en 0x0
[ 1213.273259] stream_cif_mipi_id0: close video, entity use_count 0

Media device information

  • media-ctl -p
root@orangepicm4:~# media-ctl -p
Media controller API version 5.10.160

Media device information
------------------------
driver          rkcif
model           rkcif_mipi_lvds
serial          
bus info        
hw revision     0x0
driver version  5.10.160

Device topology
- entity 1: stream_cif_mipi_id0 (1 pad, 4 links)
            type Node subtype V4L flags 0
            device node name /dev/video0
	pad0: Sink
		<- "rockchip-mipi-csi2":1 [ENABLED]
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 []

- entity 5: stream_cif_mipi_id1 (1 pad, 4 links)
            type Node subtype V4L flags 0
            device node name /dev/video1
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 [ENABLED]
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 []

- entity 9: stream_cif_mipi_id2 (1 pad, 4 links)
            type Node subtype V4L flags 0
            device node name /dev/video2
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 [ENABLED]
		<- "rockchip-mipi-csi2":4 []

- entity 13: stream_cif_mipi_id3 (1 pad, 4 links)
             type Node subtype V4L flags 0
             device node name /dev/video3
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 [ENABLED]

- entity 17: rkcif_tools_id0 (1 pad, 4 links)
             type Node subtype V4L flags 0
             device node name /dev/video4
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 []

- entity 21: rkcif_tools_id1 (1 pad, 4 links)
             type Node subtype V4L flags 0
             device node name /dev/video5
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 []

- entity 25: rkcif_tools_id2 (1 pad, 4 links)
             type Node subtype V4L flags 0
             device node name /dev/video6
	pad0: Sink
		<- "rockchip-mipi-csi2":1 []
		<- "rockchip-mipi-csi2":2 []
		<- "rockchip-mipi-csi2":3 []
		<- "rockchip-mipi-csi2":4 []

- entity 29: rkcif-mipi-luma (0 pad, 0 link)
             type Node subtype V4L flags 0
             device node name /dev/video7

- entity 32: rockchip-mipi-csi2 (5 pads, 29 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev0
	pad0: Sink
		[fmt:UYVY8_2X8/1920x1080 field:none colorspace:smpte170m
		 crop.bounds:(0,0)/1920x1080
		 crop:(0,0)/1920x1080]
		<- "rockchip-csi2-dphy1":1 [ENABLED]
	pad1: Source
		-> "stream_cif_mipi_id0":0 [ENABLED]
		-> "stream_cif_mipi_id1":0 []
		-> "stream_cif_mipi_id2":0 []
		-> "stream_cif_mipi_id3":0 []
		-> "rkcif_tools_id0":0 []
		-> "rkcif_tools_id1":0 []
		-> "rkcif_tools_id2":0 []
	pad2: Source
		-> "stream_cif_mipi_id0":0 []
		-> "stream_cif_mipi_id1":0 [ENABLED]
		-> "stream_cif_mipi_id2":0 []
		-> "stream_cif_mipi_id3":0 []
		-> "rkcif_tools_id0":0 []
		-> "rkcif_tools_id1":0 []
		-> "rkcif_tools_id2":0 []
	pad3: Source
		-> "stream_cif_mipi_id0":0 []
		-> "stream_cif_mipi_id1":0 []
		-> "stream_cif_mipi_id2":0 [ENABLED]
		-> "stream_cif_mipi_id3":0 []
		-> "rkcif_tools_id0":0 []
		-> "rkcif_tools_id1":0 []
		-> "rkcif_tools_id2":0 []
	pad4: Source
		-> "stream_cif_mipi_id0":0 []
		-> "stream_cif_mipi_id1":0 []
		-> "stream_cif_mipi_id2":0 []
		-> "stream_cif_mipi_id3":0 [ENABLED]
		-> "rkcif_tools_id0":0 []
		-> "rkcif_tools_id1":0 []
		-> "rkcif_tools_id2":0 []

- entity 38: rockchip-csi2-dphy1 (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev1
	pad0: Sink
		[fmt:UYVY8_2X8/1920x1080@10000/600000 field:none colorspace:smpte170m]
		<- "m00_b_tc35874x 1-000f":0 [ENABLED]
	pad1: Source
		-> "rockchip-mipi-csi2":0 [ENABLED]

- entity 43: m00_b_tc35874x 1-000f (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev2
	pad0: Source
		[fmt:UYVY8_2X8/1920x1080@10000/600000 field:none colorspace:smpte170m]
		[dv.caps:BT.656/1120 min:1x1@0 max:10000x10000@310000000 stds:CEA-861,DMT,CVT,GTF caps:interlaced,progressive,reduced-blanking,custom]
		[dv.detect:BT.656/1120 1920x1080p60 (2200x1125) stds: flags:]
		[dv.current:BT.656/1120 1920x1080p60 (2200x1125) stds: flags:]
		-> "rockchip-csi2-dphy1":0 [ENABLED]
@tester58126
Copy link

tester58126 commented Jan 24, 2024 •
edited
Loading

I am experiencing the same problem. I am using radxa zero 3w (rk3566) + tc358743 configuration.
TC358743->csi2_dphy0->MIPI_CSI2->RKCIF_MIPI_LVDS

scpcom pushed a commit to scpcom/linux that referenced this issue Feb 25, 2024
@LiBaokun96 @gregkh
ext4: avoid online resizing failures due to oversized flex bg
6d2cbf5 
[ Upstream commit 5d1935a ]

When we online resize an ext4 filesystem with a oversized flexbg_size,

     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
     mount $dev $dir
     resize2fs $dev 16G

the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ rockchip-linux#314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
 <TASK>
 __kmalloc_large_node+0xa2/0x200
 __kmalloc+0x16e/0x290
 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0xf0/0x150
 do_syscall_64+0x3b/0x90
==================================================================

This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:

 (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.

Signed-off-by: Baokun Li <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
scpcom pushed a commit to scpcom/linux that referenced this issue Apr 28, 2024
@sm00th @gregkh
arm64: bpf: fix 32bit unconditional bswap
087dc50 
[ Upstream commit a51cd6b ]

In case when is64 == 1 in emit(A64_REV32(is64, dst, dst), ctx) the
generated insn reverses byte order for both high and low 32-bit words,
resuling in an incorrect swap as indicated by the jit test:

[ 9757.262607] test_bpf: rockchip-linux#312 BSWAP 16: 0x0123456789abcdef -> 0xefcd jited:1 8 PASS
[ 9757.264435] test_bpf: rockchip-linux#313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 ret 1460850314 != -271733879 (0x5712ce8a != 0xefcdab89)FAIL (1 times)
[ 9757.266260] test_bpf: rockchip-linux#314 BSWAP 64: 0x0123456789abcdef -> 0x67452301 jited:1 8 PASS
[ 9757.268000] test_bpf: rockchip-linux#315 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 jited:1 8 PASS
[ 9757.269686] test_bpf: rockchip-linux#316 BSWAP 16: 0xfedcba9876543210 -> 0x1032 jited:1 8 PASS
[ 9757.271380] test_bpf: rockchip-linux#317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 ret -1460850316 != 271733878 (0xa8ed3174 != 0x10325476)FAIL (1 times)
[ 9757.273022] test_bpf: rockchip-linux#318 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe jited:1 7 PASS
[ 9757.274721] test_bpf: rockchip-linux#319 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 jited:1 9 PASS

Fix this by forcing 32bit variant of rev32.

Fixes: 1104247 ("bpf, arm64: Support unconditional bswap")
Signed-off-by: Artem Savkov <[email protected]>
Tested-by: Puranjay Mohan <[email protected]>
Acked-by: Puranjay Mohan <[email protected]>
Acked-by: Xu Kuohai <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
scpcom pushed a commit to scpcom/linux that referenced this issue Jun 5, 2024
@LiBaokun96 @gregkh
ext4: avoid online resizing failures due to oversized flex bg
cd1f93c 
[ Upstream commit 5d1935a ]

When we online resize an ext4 filesystem with a oversized flexbg_size,

     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
     mount $dev $dir
     resize2fs $dev 16G

the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ rockchip-linux#314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
 <TASK>
 __kmalloc_large_node+0xa2/0x200
 __kmalloc+0x16e/0x290
 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0xf0/0x150
 do_syscall_64+0x3b/0x90
==================================================================

This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:

 (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.

Signed-off-by: Baokun Li <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
scpcom pushed a commit to scpcom/linux that referenced this issue Jun 5, 2024
@LiBaokun96 @gregkh
ext4: avoid online resizing failures due to oversized flex bg
b183fe8 
[ Upstream commit 5d1935a ]

When we online resize an ext4 filesystem with a oversized flexbg_size,

     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
     mount $dev $dir
     resize2fs $dev 16G

the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ rockchip-linux#314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
 <TASK>
 __kmalloc_large_node+0xa2/0x200
 __kmalloc+0x16e/0x290
 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0xf0/0x150
 do_syscall_64+0x3b/0x90
==================================================================

This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:

 (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.

Signed-off-by: Baokun Li <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tester58126 @floydelcy