Re: [PATCH v3 00/11] CSI2RX support on J721E

[Pratyush Yadav <p.yadav@ti.com>]

Hi Tomi,

On 01/07/21 10:56AM, Tomi Valkeinen wrote:
> Hi Pratyush,
> 
> On 24/06/2021 22:21, Pratyush Yadav wrote:
> > Hi,
> > 
> > This series adds support for CSI2 capture on J721E. It includes some
> > fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> > driver, and finally adds the TI CSI2RX wrapper driver.
> > 
> > This series used to include the DPHY and DMA engine patches as well, but
> > they have been split off to facilitate easier merging. Patch 3 is
> > build-dependent on the DPHY series [0].
> > 
> > The DMA engine patch [1] can go in any order since that is only a run
> > time dependency. Things probably won't work without it but it will still
> > build fine.
> > 
> > Tested on TI's J721E with OV5640 sensor.
> 
> I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
> 
> Here are some notes from quick tests:
> 
> Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
> 
> When I load the modules, I get:
> 
> [  237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c

I see this with CAL's OV5640 overlay as well. I think this is caused by 
the endpoint nodes on csi-bridge and sensor pointing to each other. I 
can't quite understand any bad implications of this warning since 
everything seems to work correctly.

Should we model the connections between the sensor and CSI bridge 
differently to not cause a cycle in the graph? Or can we just ignore 
this warning since things seem to work fine despite it?

> 
> I get a warning from DMA-API debug:
> 
> [  298.774236] ------------[ cut here ]------------
> [  298.779109] DMA-API: ti-udma 31150000.dma-controller: mapping sg segment longer than device claims to support [len=1900544] [max=65536]
> [  298.791331] WARNING: CPU: 1 PID: 605 at kernel/dma/debug.c:1172 debug_dma_map_sg+0x304/0x390
> [  298.799764] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
>  drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [  298.824656] CPU: 1 PID: 605 Comm: cam-mplex.py Not tainted 5.13.0-rc4-00417-g3331992006e9 #3
> [  298.833079] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [  298.838900] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [  298.844895] pc : debug_dma_map_sg+0x304/0x390
> [  298.849245] lr : debug_dma_map_sg+0x304/0x390
> [  298.853593] sp : ffff800014dcf730
> [  298.856899] x29: ffff800014dcf730 x28: ffff00080154a880 x27: ffffffffffffffff
> [  298.864032] x26: 0000000000000000 x25: 0000000000000002 x24: 0000000000000001
> [  298.871164] x23: ffff80001163abe0 x22: 0000000000000000 x21: 0000000000000001
> [  298.878295] x20: ffff000801fa3010 x19: ffff000807585300 x18: 0000000000000000
> [  298.885426] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030
> [  298.892558] x14: 6e61687420726567 x13: 6e6f6c20746e656d x12: ffff800011a91578
> [  298.899689] x11: 00000000000c0000 x10: ffff8000116b18f8 x9 : ffff8000100eabe0
> [  298.906820] x8 : ffff8000116598f8 x7 : ffff8000116b18f8 x6 : 0000000000000001
> [  298.913951] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800011260000
> [  298.921082] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080673b000
> [  298.928214] Call trace:
> [  298.930653]  debug_dma_map_sg+0x304/0x390
> [  298.934655]  dma_map_sg_attrs+0x70/0xb0
> [  298.938487]  drm_gem_map_dma_buf+0x6c/0xf0 [drm]

I still can't reproduce this, and I think this might be why. I am saving 
the stream to a file and then replaying on my PC. You seem to be sending 
it to a display. The DMA warning looks to be coming from DRM side, not 
CSI.

Anyway, I think this is not a big problem. The UDMA driver simply does 
not populate max_segment_size, so dma_get_max_seg_size() returns 64 KiB 
as default. The hardware can actually support virtually unlimited 
segment size for TR mode and 2^27 bytes for packet mode. CSI uses TR 
mode so it can certainly handle more than 64 KiB long segments. I am not 
sure which mode DRM uses but 2^27 is still much bigger than 1900544.

Long story short, this warning has little to do with the CSI patches 
here and can be safely ignored IMO.

> [  298.943185]  __map_dma_buf+0x28/0x80
> [  298.946756]  dma_buf_map_attachment+0xe4/0x220
> [  298.951191]  vb2_dc_map_dmabuf+0x3c/0x150
> [  298.955194]  __prepare_dmabuf+0x1dc/0x514
> [  298.959197]  __buf_prepare+0x1a0/0x25c
> [  298.962938]  vb2_core_qbuf+0x3d4/0x72c
> [  298.966679]  vb2_qbuf+0x9c/0xf4
> [  298.969814]  vb2_ioctl_qbuf+0x68/0x7c
> [  298.973468]  v4l_qbuf+0x54/0x70
> [  298.976603]  __video_do_ioctl+0x194/0x400
> [  298.980603]  video_usercopy+0x374/0xa14
> [  298.984431]  video_ioctl2+0x24/0x4c
> [  298.987912]  v4l2_ioctl+0x4c/0x70
> [  298.991222]  __arm64_sys_ioctl+0xb4/0xfc
> [  298.995138]  invoke_syscall+0x50/0x120
> [  298.998885]  el0_svc_common.constprop.0+0x68/0x104
> [  299.003667]  do_el0_svc+0x30/0x9c
> [  299.006976]  el0_svc+0x2c/0x54
> [  299.010025]  el0_sync_handler+0x1a8/0x1ac
> [  299.014025]  el0_sync+0x198/0x1c0
> [  299.017333] irq event stamp: 98582
> [  299.020727] hardirqs last  enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
> [  299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [  299.037144] softirqs last  enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [  299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> [  299.054164] ---[ end trace bfe019acb2a9a04f ]---
> 
> I get a warning from media graph walk:

Fixed this one. It was caused by the graph_mutex not being held.

> 
> [  299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
> [  299.076005] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
>  drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [  299.100889] CPU: 1 PID: 605 Comm: cam-mplex.py Tainted: G        W         5.13.0-rc4-00417-g3331992006e9 #3
> [  299.110698] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [  299.116518] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [  299.122513] pc : media_graph_walk_next+0x268/0x2cc
> [  299.127295] lr : media_graph_walk_next+0x264/0x2cc
> [  299.132076] sp : ffff800014dcfa40
> [  299.135382] x29: ffff800014dcfa40 x28: 0000000000000000 x27: 0000000040045612
> [  299.142514] x26: 0000000000000001 x25: ffff800010d890f0 x24: ffff0008055c8148
> [  299.149645] x23: ffff0008055c8148 x22: ffff80001182bc40 x21: ffff80001163e2e8
> [  299.156776] x20: ffff80001182bbd0 x19: ffff0008055c8cb8 x18: 0000000000000000
> [  299.163907] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
> [  299.171037] x14: 0000000000000002 x13: 0000000000007e6f x12: 0000000000000002
> [  299.178169] x11: 0000000000040464 x10: 00000000916d3a5c x9 : ffff8000093110c0
> [  299.185301] x8 : ffff000807583d88 x7 : 0000000000000000 x6 : ffff00080673b900
> [  299.192431] x5 : 000000000000000a x4 : ffff000807583d80 x3 : ffff800011260000
> [  299.199562] x2 : 00000000000000c0 x1 : 00000000000000c0 x0 : 0000000000000000
> [  299.206693] Call trace:
> [  299.209133]  media_graph_walk_next+0x268/0x2cc
> [  299.213568]  ti_csi2rx_start_streaming+0xe0/0x5c8 [j721e_csi2rx]
> [  299.219569]  vb2_start_streaming+0x70/0x160
> [  299.223745]  vb2_core_streamon+0x9c/0x1a0
> [  299.227745]  vb2_ioctl_streamon+0x68/0xbc
> [  299.231747]  v4l_streamon+0x30/0x40
> [  299.235230]  __video_do_ioctl+0x194/0x400
> [  299.239230]  video_usercopy+0x374/0xa14
> [  299.243058]  video_ioctl2+0x24/0x4c
> [  299.246539]  v4l2_ioctl+0x4c/0x70
> [  299.249847]  __arm64_sys_ioctl+0xb4/0xfc
> [  299.253764]  invoke_syscall+0x50/0x120
> [  299.257508]  el0_svc_common.constprop.0+0x68/0x104
> [  299.262291]  do_el0_svc+0x30/0x9c
> [  299.265599]  el0_svc+0x2c/0x54
> [  299.268648]  el0_sync_handler+0x1a8/0x1ac
> [  299.272647]  el0_sync+0x198/0x1c0
> [  299.275956] irq event stamp: 98754
> [  299.279349] hardirqs last  enabled at (98753): [<ffff800010bf216c>] _raw_spin_unlock_irqrestore+0x9c/0xc0
> [  299.288900] hardirqs last disabled at (98754): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [  299.296716] softirqs last  enabled at (98606): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [  299.305138] softirqs last disabled at (98585): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> 
> Unloading the modules gives me:

Fixed this too. Both cdns-csi2rx and j721e-csi2rx share the same power 
domain, but only j721e-csi2rx contains the power-domains property. If 
you load cdns-csi2rx before j721e-csi2rx then the PD is not active and 
register access causes an abort. Fixed by adding power-domains to the 
csi-bridge node.

> 
> ERROR:   Unhandled External Abort received on 0x80000001 from S-EL1
> ERROR:   exception reason=0 syndrome=0xbf000000
> Unhandled Exception from EL1
[...]

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.