TDA4VH-Q1: Kernel crash due to clean dma

It is commented that any task of flushing the cache or encoding can run normally. There will only be problems when two of them are running concurrently.

Hello,

I will not have time to look at this until next week. Please give me time to formulate questions and reproduce this issue. Thank you for your patience.

Regards,
Sarabesh S

Okay, if you have any questions or find out, please communicate in time.

Hi Sarabesh,

Quickly reproduced the issue on the EVM.

1. You can unzip the following code on the path "ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/vision_apps/apps/basic_demos"

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/Freetech_5F00_test.7z

2.Rebuild the vision_app 

ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/sdk_builder$ make vision_apps

3. It will be generate "freetech_test.out" on the "ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/vision_apps/out/J784S4/A72/LINUX/release/freetech_test.out"

4. Copy it to the SD card and execute it.

Hi,

What buffer is allocated for v4l2 encoding? What DMA pool is this allocated from? 

If the buffer is already allocated from a kernel-managed DMA pool, it should already be coherent. There shouldn't be any need to perform a Cache flush operation on it.

regards

Suman

Suman,

I agree with you this buffer should be cache coherency on the Linux and no need cache flush operation on it. We just want to check why it will be crash if flush cache and encode at the same time.

Hi Kangjia, 

I am not sure and would still need to do more testing, but I believe there must be some setup that that the VPU depends on the cache when doing the encode_deal_task. And when the the cache is flushed it causes the panic. I will test with commenting out the cache-flush p-thread and insert the appMemCacheWb function in between the different steps of the encode_deal_task function to see where exactly the kernel crash happens.

Regards,
Sarabesh S

Hi Kangjia,

Kangjia Dong said:

flush cache and encode at the same time.

What do you mean by this? This is not how traditional DMA or device buffer sharing should work. You need to finish the DMA operation (signalling end of CPU-access) before you give a buffer to the device.

Do you have a stand-alone test case of invoking the API and creating a crash? If so, this might very well be a case of misuse. 

regards

Suman

Hi Suman,

Yes,  the stand alone test are attached in previously replied "Freetech_test.7z" 

Hi, Sarabesh, as you say，I can understand it that way: when A72 and APU use the same address memory and both attempt to flush the cache, it may cause A72 kernel crash?

Yes, I believe that some part of the encode_deal_task is causing this conflict. I haven't had enough b/w to see if this test will produce any helpful results yet.

Best,
Sarabesh S

Hello, 

Can you provide some context/intent to having a cache-flush operation while simultaneously running an encode task? Our wave5-driver avoids using these cache operations since the encoder can only read/write DDR. 

Thanks,
Sarabesh S.

The current demo is an example of a problem triggered, but in fact there are other scenarios where this problem will occur. For example, the A72 allocates a piece of memory, copies an image into this memory, flushes the cache after the copy is completed, and then imports buf. Go to the m2m node for color conversion, and this piece of memory is also encoded. Copying, color conversion, and encoding are all in different threads, which will trigger this problem.

Hi, Sarabesh, in the previous description,  the cache that VPU depends on,  is A72 Cache or VPU own Cache? I would like to know if there is conflict in Cache between A72 and VPU, or between A72 and VPU accessing DDR？

Ok，thanks，as you say, may I can understand as follows: the reason why FT‘s demo happen A72 kernel crash is that a cache flush for the DMABUF may be illegal，may be the VPU is reading the DMABUF memory now and then may be cause memory coherency issues？

Hello, 

Sorry for the delayed response, but yes that is what I believe to be the case here. That is why when commenting out either the flush operation or encoder operation the FT demo operates without error.

Thank you,
Sarabesh S.