Handling when MPU crashes, eg. CTRL-C on MPU side.
authorBuddy Liong <a0270631@ti.com>
Thu, 7 Jan 2016 21:28:41 +0000 (15:28 -0600)
committerBuddy Liong <a0270631@ti.com>
Mon, 2 Oct 2017 15:20:14 +0000 (10:20 -0500)
commit7942b6bdafe15b8b3aefbb5894327c140a7e6504
tree1828da61b20660263e48a08352d5d8b80ea4ea8d
parentd135cc9f7d000f715cceb272f7e93019b4af917c
Handling when MPU crashes, eg. CTRL-C on MPU side.

During low latency encode and decode, when MPU is crashing
DCE server is not handling the clean up properly which can cause
the system to hang afterward.

Based on the information from the codec support, since process call
is in blocked state, the client needs to send proper numBlocks for
codec to return the process call properly.

In H.264 low latency encoder, codec will call function callback
H264E_GetDataFxn to get the numBlocks, when MPU has crashed, DCE
server needs to propagate the numBlocks to codec so that codec can
proceed and return the process call.
There are 2 alternatives, one is to return proper numBlocks based
on resolution, the other is to return bogus numBlocks which is big
enough for codec to detect an error and return the process call.
This task implements the returning bogus '100' numBlocks to codec
because the implementation for proper numBlocks requires some
calculation to be implemented and the input buffer will not have
proper data anyway.

In H.264 low latency decoder, codec will call function callback
H264D_PutDataFxn to post the numBlocks to client, when MPU has
crashed, DCE server should ignore this information and return
immediately. There could be multiple callback from codec until codec
reach the proper numBlocks and DCE server should ignore and return
immediately.

Change-Id: I56c0f3b5792504e18d2fb2a57a3c34d26f0b55e5
Signed-off-by: Buddy Liong <a0270631@ti.com>
src/ti/framework/dce/dce.c