AM5728: VIP port treating signal loss as overflow?

Chris, 

It seems that no-signal the pixel clock is flat during no-signal period. Can you confirm you are supplying the pixel clock when sending the test pattern?

thanks

Jian

Jian,

The test pattern will be supplied at the application level in the event that a loss of signal is detected. We do not send the test pattern into the VIP, rather, it is supplied from a fixed image stored in RAM. Therefore, there may be no pixel clock present during this time.

Thus what we need is a method to detect the loss of signal (e.g. no pixel clock) within the VIP driver and return an error condition, but currently the driver goes into a recovery loop.

We wish to understand how the recovery is triggered in the absence of signal (i.e. why there is an overflow interrupt) and how to obtain an error condition in this case so that our software test pattern can be substituted until the hard signal is again present.

---Chris

Jian,

Please post your response now, the thread is unlocked.

Regards

Karthik

No, so far I have not found a way to achieve the desired behavior using the FIFO interrupt.

Upon further investigation, the problematic PORTx_OUTPUT_FIFO interrupt behavior seems to happen only after system reset and only if there has not been any signal present with a good capture on the VIP port. Following any valid capture on the port, the overflow condition does not occur except when expected (i.e. as an indicator of bad signal or insufficient memory bandwidth).

Therefore the post-reset no-signal overflow problem is most likely a VIP driver bug which results from some initial reset condition that is cleared by a valid capture.

Enabling debug, I do not see the DISCONN event occur if signal is lost. When would it be expected? (In the TRM it is implied that this interrupt would be applicable only to pixel-multiplexed capture, which we do not use and which appears not to be supported by the TI driver.)

Chris, 

Not sure I am getting clear description of events from the TRM. I will chase some internal documentation.

In the mean time, are you able to create a loss condition on your hardware, and check which Parser events get triggered?  there seems no hardware detection of flat clock lines, therefore, we need to look for events that is triggered by Parser Size Register, which calculates sizes by received clocks. Prob. first unmask all ~20 Parser events, then check FIQ status register upon loss and see which event get set. that will give us a focus. 

regards

jian

Did you have any luck finding better documentation on the VIP events?

When I enable all of the parser interrupts per your request, the problem does not occur. Oddly, I get a PORTA_CONN event even though no signal is present.

Here's the relevant kernel log:

[1704.558711] vin2a-0: vip_open
[ 1704.572808] vin2a-0: s_fmt input fourcc:YUYV size: 1920x1080 bpl:0 img_size:0
[ 1704.580003] vin2a-0: try_fmt fourcc:YUYV size: 1920x1080
[ 1704.588317] vin2a-0: try_fmt loop:0 fourcc:YUYV size: 1920x1080
[ 1704.594277] vin2a-0: try_fmt loop:0 found new larger: 1920x1080
[ 1704.600583] vin2a-0: try_fmt loop:0 found at least larger: 1920x1080
[ 1704.606976] vin2a-0: try_fmt loop:0 found new best: 1920x1080
[ 1704.612788] vin2a-0: try_fmt loop:0 found direct match: 1920x1080
[ 1704.619513] vin2a: calc_format_size: fourcc:YUYV size: 1920x1080 bpl:3840 img_size:4147200
[ 1704.627833] vin2a-0: s_fmt try_fmt fourcc:YUYV size: 1920x1080 bpl:3840 img_size:4147200
[ 1704.635972] vin2a-0: s_fmt fourcc:YUYV size: 1920x1080 bpl:3840 img_size:4147200i
1605828751.329073 com I 1057 capper.cpp:71: open: /dev/video2[ 1704.643547] vin2a-0: s_fmt pix_to_mbus mbus_code: 2006 size: 1920x1080
[ 1704.655397] vipsub s_fmt w 1920 h 1080 f 7
[ 1704.671353] vin2a-0: s_fmt subdev s_fmt mbus_code: 2006 size: 1920x1080 ft: 33366667

[ 1704.679486] vin2a-0: s_fmt vpdma data type: 0x07
[ 1704.685260] vin2a-0: get 8 buffer(s) of size 4147200 each.
[ 1704.710159] vin2: vip_set_slice_path:
[ 1704.713861] vin2: vip_set_slice_path: DATA_PATH_SELECT(00000110): 80008000
[ 1704.720783] vin2: vip_set_slice_path:
[ 1704.724477] vin2: vip_set_slice_path: DATA_PATH_SELECT(00000110): 40008000
[ 1704.731671] vin2: using ACTVID
[ 1704.734767] vin2a-0: vip_load_vpdma_list_fifo: start_dma vb2 buf idx:0
[ 1704.742467] vin2a-0: vip_load_vpdma_list_fifo: start_dma vb2 buf idx:1
[ 1704.774176] vin2: handle_parser_irqs: FIQ_STATUS: 0x00000400
[ 1704.779867] vin2: VIP_PORTA_CONN
[ 1704.783153] vin2: handle_parser_irqs: FIQ_STATUS: 0x00004000
[ 1704.788837] vin2: VIP_PORTA_SRC0_SIZE
[ 1704.792561] vin2: handle_parser_irqs: FIQ_STATUS: 0x00004000
[ 1704.798245] vin2: VIP_PORTA_SRC0_SIZE

... and this continues with SRC0_SIZE interrupts in this manner continuously.

Chris, 

sorry for the extended delay. there were no additional details I was able to find. Were you able to explore more on PORTA_CONN event?

Jian

No, in the absence of any documentation or further help from TI.

However, it appears that PORTA_CONN thing is just one manifestation of a larger problem, still not solved: the VIP hardware and/or driver can get into some unrecoverable states which may occur sometimes at power-on or frequently occur when the VIP input signal is removed or changes formats; a hard reset is usually required to recover from these states.

The following sequence is repeatable for us:

1. VIP is correctly streaming from port in some standard format.
2. VIP signal drops and changes to another format. Parser error does not occur. 
3. Application observes format change from the v4l2 subdevice and does STREAMOFF on that port. DMABUFs are released.
4. Port is closed, re-opened, and S_FMT done with the new format information, and new buffers allocated and queued to driver.
5. STREAMON is issued. Driver sends two buffers from the queue to the VPDMA, but they are never filled.
6. Consequently no buffers are able to be dequeued from the V4L2 interface even though the input signal is valid. 

I found that there is a vip_recovery_work() procedure which is scheduled in response to a parser error interrupt and resets the VIP device. Since we do not get the parser error interrupt in this case, I attempted scheduling (and waiting for) vip_recovery_work directly during e.g. the STREAMON operation, but it crashes, apparently because it expects buffers to be in process.

How can we achieve reliable VIP operation across format changes, signal interruptions, and power cycles?

Chris, 

Description of steps points to some driver issues where error handling and STREAMOFF->STREAMON is not clean. I will ask our driver team to take a look and see if they can spot any thing. 

with another apology for the delays 

Jian