Hi there,
We are having a problem with the VDCE driver that may be the same, or similar, to that described in the post called "vdce/display driver hang on DM6467T":
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/30631/106797.aspx#106797
In our case the "hang" happens after a few minutes converting frames from 422 to 420. We use separate buffers for source and destination. Our system includes VPIF capture, VDCE color conversion, DSP encoding processing and TSIF output data transmission. After some research, we have seen that the problem –at least in our case- is that VDCE IRQ is sometimes not triggered, or at least the vdce_isr() routine is never reached, and the system stalls in:
ret = wait_for_completion_interruptible(&(device_config.sem_isr));
inside vdce_start() function in davinci_vdce.c.
We have traced the following registers trying to get some insight of the behavior of the VDCE hardware and the ARM interruptions architecture:
VDCE registers:
-CTRL (VDCE_GO bit)
-INTEN
-INTEN_SET
-INTSTAT
ARM registers:
-EINT0 (VDCEINT = 12)
-IRQ0
Let’s assume an initial state in which all interrupts are enabled and INTSTAT has just been “manually” cleared (writing “1” to INTEN_CLR)
|
|
Initial state |
After vdce_hw_setup() |
After vdce_enable() |
After wait_for_completion_interruptible_timeout() |
|
VDCE_GO |
0 |
0 |
1 |
0 |
|
INTEN |
1 |
1 |
1 |
1 |
|
INTEN_SET |
1 |
1 |
1 |
1 |
|
INTSTAT |
0 |
0 |
0 |
1 |
|
EINT0 |
0x31c03 |
0x31c03 |
0x31c03 |
0x31c03 |
|
IRQ0 |
0xFFFFFFFF |
0xFFFFFFFF |
0xFFFFFFFF |
0xFFFFFFFF |
We used wait_for_completion_interruptible_timeout() to avoid the system to stall inside the completion function, and we traced wether the program has passed through vdce_isr() or not. In “normal functioning” the values of the registers are as in the chart above, and the program goes through vdce_isr(). But when the system gets stalled (or in our case, when the completion is left by timeout) we observe exactly the same values for the registers in the chart above, and the only difference is that the ISR has never been reached. In fact, it is possible to “escape” from the stall by setting again the “GO” bit to 1 in the CTRL register and start the proccess once more.
At this point, we have some questions:
-INTSTAT seems not to be cleared anywhere in the original driver, and despite of that, it seems to work in general. Therefore, it seems the VDCE interrupt is edge triggered. But is the VDCEINT (ARM interrupt number 12 in IRQ0) “physically” connected to the INTSTAT bit? Or what exactly is the relationship between INTSTAT and the GO bit in the VDCE driver and the VDCEINT in the ARM? The behavior of INTSTAT seems to be ok (if we clear it to 0 before enabling the GO bit, it becomes 1 again after a frame is processed), but the interruption is not always triggered –or attended-.
Thanks in advance