Hello!
I'm using the resizer on a DM368 to create multiple frame buffers from the same input buffer. I'm operating in single shot mode and resizing YUV422 buffers to YUV420SP. So there are multiple IOCTLs to the resizer in very short time like in this pseudo-code:
ioctl(resizer_fd, RSZ_S_CONFIG, &rsz_chan_config_first);
ioctl(resizer_fd, RSZ_RESIZE, &rsz_first);
ioctl(resizer_fd, RSZ_S_CONFIG, &rsz_chan_config_second);
ioctl(resizer_fd, RSZ_RESIZE, &rsz_second);
Now sometimes the second RSZ_RESIZE deadlocks. After some investigation I found that the call blocks in "imp_common_start" when doing "wait_for_completion_interruptible". Changing this to "wait_for_completion_interruptible_timeout" and checking the INTSTAT register in the case of a timeout I see that the RSZ_INT_DMA is never raised. So it seems the DMA for some reason died and there's no error handling.
Changing the CLK_DIV ratio changes the probability of the deadlock. With 10/20 it deadlocks nearly every time. With 10/30 it deadlocks every 100 frames or so. With 10/40 I could not observe a deadlock within some 1000 frames - which does not mean that it will not happen in the future.
Is there any way to find the "correct" maximum values for the CLK_DIV M/N?
Regards,
Andreas.
Andreas,
Can you please put some delay between your first RSZ_RESIZE IOCTL and second RSZ_S_CONFIG IOCTL, and repeat the same for all further operations?
For the clock divider values, there is no rule of thumb to calculate the exact values for CLK_DIV M and N. The values very much depend upon your system load. But i dont think the problem is related to just CLK_DIV over here. I feel the problem is about the enable bit being cleared for all the modules, specially IPIPEIF. So if you wait between two consecutive resize calls, most likely IPIPEIF bit should be cleared and you should not hit the problem.
Can you also tell me the LPFR and PPLN values you are programming for the resize operation in RSZ_S_CONFIG?
Anshuman
PS: Please mark this post as verified, if you think it has answered your question. Thanks.
Hi, AnshumanI encounter exactly the same problem.I added YUV420SP input sopport in montavista linux-2.6.18 as your direction in http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7583/29901.aspx#29901. But when I do resize Y after a few RSZ_RESIZE ioctl, it hangs in "wait_for_completion_interruptible" funtion in /driver/char/imp_common.c.My case is to resize D1 resolution to XGA resolution.LPFR = rsz_ss_config.input.image_height + 10; (576+10)PPLN = rsz_ss_config.input.image_width + 8;(704+8)I put some delay(like usleep(100)) between my Resize_420SP() funtion which has two RSZ_RESIZE ioctls and two RSZ_S_CONFIG ioctls for resizing Y and CbCr componet separately. It runs about an hour before hanging. It seems that delay isn't useful in deed. Is it the only solution of this problem? Need I configure DMA_RZA and DMA_RZB to a fine value in VPFE? Because after I configure DMA_RZA = 0x20 or 0x40 it still will hang.Please help me! Thank you very much!lush
Was this problem ever solved? It sounds very similar to what I am experiencing.
One very simple check that we should put before calling RESIZE ioctl is that we confirm that IPIPEIF Mode.Enable bit and RSZA, RSZB enable bit - all are cleared to 0. This means the previous resize operation is indeed completed.
The problem which we tried to solve earlier was that the user had configured IPIPEIF to have very large blanking etc and the resizer completed its operation but IPIPEIF Enable was not cleared (due to elongated blanking). So when the user was again calling RESIZE ioctl, he was seeing that everything else go programmed but the IPIPEIF enable that he was programming in second resize IOCTL was really not making a difference. The enable bit was set due to first ioctl and got cleared when the operation of IPIPEIF for first ioctl got over.
So resizer was always waiting for getting some input from IPIPEIF. The delay helped there but cleaner way is to verify the enable bits of the modules before calling the resize operation.
Hope this helps.
That did the trick, thanks!