[PATCH] media: meson: vdec: esparser: check parsing state with hardware write pointer

[Hans Verkuil]

Hi Christian,

On 23/01/2023 13:04, Dan Carpenter wrote:
> On Mon, Jan 23, 2023 at 09:43:00AM +0000, Christian Hewitt wrote:
>> From: Neil Armstrong <narmstrong at baylibre.com>
>>
>> Also check the hardware write pointer to check if ES Parser has stalled.
>>
> 
> Presumably this is something which has happens in real life?  Say a user
> has this hardware and is wondering if this patch fixes their bug, what
> does this bug look like to them?
> 
> Please add a Fixes tag.

I'm marking this as Changes Requested in patchwork.

Dan has good comments, and in general, if something is 'weird', then
it needs to be commented carefully.

Regards,

	Hans

> 
>> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
>> Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
>> ---
>>  drivers/staging/media/meson/vdec/esparser.c | 15 +++++++++++----
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/media/meson/vdec/esparser.c b/drivers/staging/media/meson/vdec/esparser.c
>> index df5956c6141d..41b705f999b2 100644
>> --- a/drivers/staging/media/meson/vdec/esparser.c
>> +++ b/drivers/staging/media/meson/vdec/esparser.c
>> @@ -300,6 +300,7 @@ esparser_queue(struct amvdec_session *sess, struct vb2_v4l2_buffer *vbuf)
>>  	u32 num_dst_bufs = 0;
>>  	u32 offset;
>>  	u32 pad_size;
>> +	u32 wp, wp2;
>>  
>>  	/*
>>  	 * When max ref frame is held by VP9, this should be -= 3 to prevent a
>> @@ -354,15 +355,21 @@ esparser_queue(struct amvdec_session *sess, struct vb2_v4l2_buffer *vbuf)
>>  	}
>>  
>>  	pad_size = esparser_pad_start_code(core, vb, payload_size);
>> +	wp = amvdec_read_parser(core, PARSER_VIDEO_WP);
>>  	ret = esparser_write_data(core, phy, payload_size + pad_size);
>> +	wp2 = amvdec_read_parser(core, PARSER_VIDEO_WP);
>>  
> 
> Why is check not done inside the esparser_write_data() function?  It
> really feels like doing a write where nothing happens should be a bug
> for both callers...
> 
> The esparser_write_data() function returns > 0 on success, 0 on timeout
> (I guess timeout is an error-ish) and negative if the user presses
> CTR-C.  There are no comments to explain the unusual returns.  Could we
> clean this up so it just returns negatives on error and zero on success
> or if not then let's add a comment explaining what's going on?
> 
>>  	if (ret <= 0) {
>> -		dev_warn(core->dev, "esparser: input parsing error\n");
>> -		amvdec_remove_ts(sess, vb->timestamp);
>> -		v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>>  		amvdec_write_parser(core, PARSER_FETCH_CMD, 0);
>>  
>> -		return 0;
>> +		if (ret < 0 || wp2 == wp) {
> 
> So in this patch if there is a timeout but something was written then
> that's kind of a success path?
> 
> regards,
> dan carpenter
> 
>> +			dev_err(core->dev, "esparser: input parsing error ret %d (%x <=> %x)\n",
>> +				ret, wp, wp2);
>> +			amvdec_remove_ts(sess, vb->timestamp);
>> +			v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>> +
>> +			return 0;
>> +		}
>>  	}
>>  
>>  	atomic_inc(&sess->esparser_queued_bufs);
>