[PATCH] media: uvcvideo: Support borderline implementation of hw timestamping

[Ricardo Ribalda]

Some cameras do not set pts and src if there is no camera data in the
buffer. They do this without clearing the PTS and SCR bits of the
header. This is probably done due to a strict/borderline interpretation
of the standard:

"STC must be captured when the first video data of a video frame is put
on the USB bus."

Eg:
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a

Support those cameras by only decoding the clock if there is camera data
in the buffer.

Signed-off-by: Ricardo Ribalda <ribalda@xxxxxxxxxxxx>
---
 drivers/media/usb/uvc/uvc_video.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index e16464606b14..6d0e474671a2 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -490,6 +490,18 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
 	if (len < header_size)
 		return;
 
+	/*
+	 * Some cameras when there is no camera data in a buffer, do not
+	 * handle properly the pts and scr. This can be due to an borderline
+	 * interpretation of the standard: "STC must be captured when the
+	 * first video data of a video frame is put on the USB bus."
+	 * Due to their internal design, their firmware cannot clear the
+	 * UVC_STREAM_PTS and UVC_STREAM_SCR bits. Which forces us to use the
+	 * length of the buffer to decide if pts and scr are valid or not.
+	 */
+	if (len == header_size)
+		return;
+
 	/* Extract the timestamps:
 	 *
 	 * - store the frame PTS in the buffer structure
-- 
2.33.0.rc1.237.g0d66db33f3-goog