• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 1770 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

absent vpss dma resizer interrupts again

German Baranov
Intellectual 660 points
Other Parts Discussed in Thread: TVP5150

Hello!

I'd like to raise the question already discussed several times on TI forums, but unfortunately I failed to find clear and detailed answer to the issue. If  somebody can give me a link to explanation I will be very thankful.

The problem is dma resizer interrupt  which is not running when set up is made for full vertical resolution. You can find similar discussions here :

http://e2e.ti.com/support/embedded/linux/f/354/t/62644.aspx

http://e2e.ti.com/support/embedded/linux/f/354/t/53786.aspx

http://e2e.ti.com/support/embedded/linux/f/354/t/143585.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/219393/806734.aspx#806734

In my case, I have custom DM368 board which is supposed to be configured between PAL tvp5150 mode and 720P sensor. In case of 5150 everything works fine, while for 720P case dma resizer interrupt doesn't work, if setup is made for 720 lines. As a result of absence of the interrupt, DQBUF call stalls forever. When configured for smaller amount of lines (704 for instance) dma interrupt runs. At the same time VINT0  and VINT1 interrups run in all cases. The situation has already been described several times by other developers on the forum.

So, it looks like when triggering of VPSS is made by external SYNC  pulses, resizer needs couple extra pulses to finish frame transmission to memory (or, it can be a result of configuration error, but where should I look for this error?). PAL decoder provides a lot of additional syncs during blank interval, that's why it works without problem.

TI employees, who took part in similar discussions ( , ) mentioned that it could be a result of improper timing, but can it be explained in details: which timing adjustments are critical for the interrupt?

Thanks for any advice.

PS. I'm calling the source assigned to vpss_int5 "dma_resizer_interrupt", though in TI's VPFE user's guide (rev C) this interrupt source is still called "reserved"

PPS I've read in one of the forum threads about interesting workaround, based on replacement of interrupt source from 15 to 14 (resizer last pixel), but if 15 works OK for 720x576 and 1280x70x , probably it can be adjusted for normal work?

German Baranov

 

  • 0
    Intellectual 435 points

    Hello All,

    I too am very interested in more information regarding this issue.  I hope someone from TI will finally respond.

    Thanks,

    Chris Richardson

  • 0
    Expert 1690 points

    German,

    I've experienced the same issue, but the methods here:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/177902/783547.aspx#685829

    appear to have worked for me.  I'm using a 2.6.37 kernel, though, and had to modify the code to use the iomapped memory rather than using the davinci_* macros.  Additionally, I am only using one-shot mode and not continuous.

    I don't really understand how the hardware gets into this state, but I believe that the problem lies in hardware and not software.  There are a few messages on this forum in which people experienced the same issue when using the hardware directly and not through any kernel drivers.

    Best of luck!

    -M

  • 0 in reply to mdeneen
    Intellectual 660 points

    Hi!

    Polling ipipe enable bits didn't make any difference. Probably, it helps for single shots.

    It looks to me like resizer interrupt works differently in case of ITU.656 sync sygnals and external pulses, though it requires checking.

    What I managed to do in my case is to use different event for triggering interrupt INT5:

    Insted of "reserved" RSZ_INT_DMA Event No.15  I was using  IPIPEIF_INT Vertical sync pulse beginning event No.9

    In case of IPIPEIF_INT interrupt is triggered later then RSZ_DMA, so there is no doubt that DMA is finished and all processing works OK with interrupt reliably running. Since interrupt happens later, it leaves less time between start of processing and start of new frame data, in my case it was not an issue.

    Using IPIPEIF_INT is not exactly the same with RSZ_INT_DMA, for example for IPIPEIF_INT interrupt is triggered all the time when VSYNC pulse is present, while RSZ_INT_DMA runs only when video processing started. Since interrupt handler is not very large function for my case it was not a problem.

    Both STD tv5150 and 720P digital cam work with this modification.

    All software modifications are small and done within vpss.c file in media driver

  • 0 in reply to German Baranov
    TI__Guru**** 399330 points

    Hi,

     

    Minor change,

    IPIPEIF interrupt comes when it sees vsync, which means kind of start of frame and RSZ_INT_DMA comes when dma finishes, so processing is finished and dma is also near to finish.

     

    Rgds,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 660 points

    Let me just draw what I meant, cause I believe that we are talking about the same. And it will be easier to understand to everybody. Dashed lines are pulses above vertical resolution required to trigger RSZ_DMA_INT. 

    To be exact, what happens first: RSZ or IPIPE, depends on time between end of valid data and front of VSYNC (which, in turn, depends on image sensor design), but

    usually there is a gap, which makes IPIPE to be placed behind RSZ. 

    Best regards,

    German

  • 0 in reply to German Baranov
    TI__Guru**** 399330 points

    Hi German,

     

    Resizer interrupt is for completion of the previous (or current captured) frame, whereas ipipeif interrupt is for starting of a new frame, so ipipeif interrupt is always coming before resizer..

     

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 660 points

    Gotcha!

    Now we have TI employee joined this conversation!

    So, Brijesh, can you please tell us what can be wrong with RSZ_DMA interrupt and what professionals would recommend to do in this case, rather then discussing my home made patch?

    Yours sincerely,

    German Baranov