sar adc scan conversions issue based on BSP40 on RDB3

[hittzt]

Hi,

I noticed that S32G SDK BSP40 has been released, and I tested the sar-adc case.

But I got the following error when run scan conversion case with CONFIG_DMA_API_DEBUG enabled:

[ 53.227784] ------------[ cut here ]------------
[ 53.227796] DMA-API: iio iio:device0: device driver tries to sync DMA memory it has not allocated [device address=0x00000000ef580000] [size=16384 bytes]
[ 53.227815] WARNING: CPU: 4 PID: 0 at check_sync+0x1e0/0x630
[ 53.227834] Modules linked in: sja1110(O)
[ 53.227847] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G O 5.15.145-rt73+g3a3fafb13baa+p0 #1
[ 53.227854] Hardware name: NXP S32G399A-RDB3 (DT)
[ 53.227858] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 53.227864] pc : check_sync+0x1e0/0x630
[ 53.227870] lr : check_sync+0x1e0/0x630
[ 53.227875] sp : ffffffc008e9bc10
[ 53.227877] x29: ffffffc008e9bc10 x28: 00000000000000c0 x27: ffffffc008e502d0
[ 53.227886] x26: 00000000ef56e000 x25: ffffff8801865808 x24: 0000000000000018
[ 53.227894] x23: 00000000ef580000 x22: 0000000000010000 x21: ffffffc008d48790
[ 53.227902] x20: ffffffc008e9bc80 x19: ffffffc008e502e8 x18: ffffffffffffffff
[ 53.227910] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: ffffffc008dee606
[ 53.227918] x14: ffffffffffffffff x13: ffffffc008dee5f8 x12: 6461206563697665
[ 53.227927] x11: 645b206465746163 x10: 6f6c6c6120746f6e x9 : 0000000000004000
[ 53.227935] x8 : 6f74207365697274 x7 : 0a5d736574796220 x6 : 000000000000000b
[ 53.227943] x5 : ffffff885f850908 x4 : 0000000000000000 x3 : 0000000000000027
[ 53.227950] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88000c4240
[ 53.227959] Call trace:
[ 53.227963] check_sync+0x1e0/0x630
[ 53.227968] debug_dma_sync_single_for_cpu+0x8c/0x94
[ 53.227975] dma_sync_single_for_cpu+0xbc/0xfc
[ 53.227985] s32cc_adc_dma_cb+0x94/0x1d0
[ 53.227994] vchan_complete+0x214/0x234
[ 53.228002] tasklet_action_common.constprop.0+0x124/0x150
[ 53.228012] tasklet_action+0x28/0x34
[ 53.228018] _stext+0x11c/0x274
[ 53.228023] irq_exit+0x88/0xc4
[ 53.228029] handle_domain_irq+0x64/0x90
[ 53.228038] gic_handle_irq+0x54/0x130
[ 53.228047] call_on_irq_stack+0x20/0x4c
[ 53.228053] do_interrupt_handler+0x54/0x60
[ 53.228059] el1_interrupt+0x30/0x80
[ 53.228069] el1h_64_irq_handler+0x18/0x2c
[ 53.228074] el1h_64_irq+0x78/0x7c
[ 53.228079] arch_cpu_idle+0x18/0x2c
[ 53.228084] do_idle+0xc4/0x150
[ 53.228092] cpu_startup_entry+0x28/0x60
[ 53.228098] secondary_start_kernel+0x140/0x174
[ 53.228106] __secondary_switched+0x90/0x94
[ 53.228115] ---[ end trace ec83ba16a43bc8cb ]---

And the whole log is attached.

The reason seems that the sar-adc driver introduced new codes for DMA operations(s32cc_adc_dma_cb()), so would you please help to confirm the issue?

Thanks,

Zhantao

[chenyin_h]

Hello, @hittzt

Thanks for the question and sorry for the delay.

I feel sorry that we seldomly debug on the calltrace that may triggered aside from the default kernel configuration. If it does impact any system functionality itself, please do not hesitate to raise a new ticket, I would report it to internal teams.

I retested it on BSP39 and found the issue seems also exist, as a result, it may be introduced earlier, I may check it further when got free from heavy load.

I apologize and sorry for your inconvenience.

Best Regards

Chenyin

[chenyin_h]

Hello, @hittzt

Thanks a lot for sharing the information.

I tested it locally and found that there are no such issues with the default kernel configuration.

The issue could only be triggered by enabling the CONFIG_DMA_API_DEBUG from the kernel configuration, is it right? You were testing it with your manually built kernel? May I know if you ever met such issues with the default settings?

Thanks.

Best Regards

Chenyin

[hittzt]

Hi @chenyin_h ,

Thanks for your rapid feedback.

And it is yes that there is no such issue with default kernel configures.

The issue shows only when the CONFIG_DMA_API_DEBUG is enabled.

I am working on this issue to see the reason and with your support I think we can fix it more quickly.

Thanks,

Zhantao