• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

resizer deadlock when calling multiple times without pause

Andreas Gaeer
Intellectual 335 points

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.

 

  • 0
    TI__Mastermind 19985 points

    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?

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Prodigy 10 points

    Hi, Anshuman

    I 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

  • 0 in reply to lush
    Prodigy 90 points

    Was this problem ever solved?  It sounds very similar to what I am experiencing. 

  • 0 in reply to lush
    TI__Mastermind 19985 points

    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.

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Prodigy 90 points

    That did the trick, thanks!

  • 0 in reply to jayarr
    Expert 2150 points

    jayarr said:

    That did the trick, thanks!

    hi, Jayarr

    would please provide me more info about how you get it work ?

    we are facing the same problem. we've done many tests use dm365 resize, such as d1, vga, cif, qvga, qcif   to 800x480, all is ok except qcif failed with timeout error.

    if we change m=10, n=240 as we have done on the other resolutions , the timeout error gone.but the dist yuv is not ok.

    we'd like to ask for advices.

    thanks.

    regards, Mike