From patchwork Wed Nov 24 10:49:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans Verkuil X-Patchwork-Id: 78751 X-Patchwork-Delegate: laurent.pinchart@ideasonboard.com Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from ) id 1mpppy-009Jvb-1l; Wed, 24 Nov 2021 10:49:14 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241602AbhKXKwV (ORCPT + 1 other); Wed, 24 Nov 2021 05:52:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235858AbhKXKwV (ORCPT ); Wed, 24 Nov 2021 05:52:21 -0500 Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [IPv6:2001:888:0:108::2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E4C7C061574 for ; Wed, 24 Nov 2021 02:49:11 -0800 (PST) Received: from cust-b5b5937f ([IPv6:fc0c:c16d:66b8:757f:c639:739b:9d66:799d]) by smtp-cloud7.xs4all.net with ESMTPA id pppqmdwrSCMnAppptmvRRG; Wed, 24 Nov 2021 11:49:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s2; t=1637750950; bh=DHIYxLpPcyxDWbxjmVmPmfgDB77V6VkQ01Yz2N0g27A=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=p0UjoMFbXGwfVANTaGyfwwowjGBngzaL4bkfORyXRQS9F/Z81vsS1ulz8ia4LuWGf pRek5WQAJJIapebNUy7HUNsNfbCEDqTn1eJE+ZZIlp+o1TAzVzmIc2huKRqDM6bKg+ VSi5guWizoQp2WekgEndquiN4qScoaJHxcTRDbyaqFPe0LzUBonc0JAZnmLpv6OHBJ LViqnq/Q3SJLW9hAPpf7jPrr39+lEkZmY7s52Hqm0nvC4q6yMro1jqdIDgYkD256CM KmyTR2t70Ct1eTZtHTkR/sbGAfjYqe7PYrFMyUEgBbuUBtNTl+3n+/cENitcUALjGd Z2FrBncQzMaQg== To: Linux Media Mailing List Cc: Laurent Pinchart , Ricardo Ribalda Delgado From: Hans Verkuil Subject: [PATCH] uvc: fix sequence counting Message-ID: <0d3ee0aa-0f1f-4670-a5cc-8dd982e2e3b0@xs4all.nl> Date: Wed, 24 Nov 2021 11:49:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Language: en-US X-CMAE-Envelope: MS4xfP8SCP6/8e6X2oUXFZcR3GJFtpCx9UoQBS7qvZqzu3umAotAw7i3wtl8Myj/J2aaaJla5NdTyjoIz5qy7+50gIfEw9HQLskt8ZkzZ5ZVw68TaHB5cLHo R+4+CzRSXN0/0T55ZGHpTbEDSpOfXMpWoRCLpeT5B+boCVnY6R+TYg8WUI5w5VXKpDWWJZnt8fpXBHDQihxUlHiRSj4YRmXs3avLyubF40as3fqfviVE7P/5 zOyAv7snHQPYwSZfV3ff6M6RFAOPusGpglqpBbagVDqAQqc26D/Dh/8kFRyb3uIs Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIMWL_WL_MED=0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no When you start streaming from uvc, then the first buffer will have sequence number 0 and the second buffer has sequence number 2. Fix the logic to ensure proper monotonically increasing sequence numbers. The root cause is not setting last_fid when you start streaming and a new fid is found for the first time. This patch also changes the initial last_fid value from -1 to 0xff. Since last_fid is unsigned, it is better to stick to unsigned values. Signed-off-by: Hans Verkuil --- drivers/media/usb/uvc/uvc_video.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index 9f37eaf28ce7..8ba8d25e2c4a 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -1055,7 +1055,10 @@ static int uvc_video_decode_start(struct uvc_streaming *stream, * that discontinuous sequence numbers always indicate lost frames. */ if (stream->last_fid != fid) { - stream->sequence++; + if (stream->last_fid > UVC_STREAM_FID) + stream->last_fid = fid; + else + stream->sequence++; if (stream->sequence) uvc_video_stats_update(stream); } @@ -1080,7 +1083,7 @@ static int uvc_video_decode_start(struct uvc_streaming *stream, /* Synchronize to the input stream by waiting for the FID bit to be * toggled when the the buffer state is not UVC_BUF_STATE_ACTIVE. - * stream->last_fid is initialized to -1, so the first isochronous + * stream->last_fid is initialized to 0xff, so the first isochronous * frame will always be in sync. * * If the device doesn't toggle the FID bit, invert stream->last_fid @@ -1111,7 +1114,7 @@ static int uvc_video_decode_start(struct uvc_streaming *stream, * last payload can be lost anyway). We thus must check if the FID has * been toggled. * - * stream->last_fid is initialized to -1, so the first isochronous + * stream->last_fid is initialized to 0xff, so the first isochronous * frame will never trigger an end of frame detection. * * Empty buffers (bytesused == 0) don't trigger end of frame detection @@ -1895,7 +1898,7 @@ static int uvc_video_start_transfer(struct uvc_streaming *stream, int ret; stream->sequence = -1; - stream->last_fid = -1; + stream->last_fid = 0xff; stream->bulk.header_size = 0; stream->bulk.skip_payload = 0; stream->bulk.payload_size = 0;