Message ID | 20220920-resend-hwtimestamp-v3-3-db9faee7f47d@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp5076545wrt; Wed, 4 Jan 2023 02:48:04 -0800 (PST) X-Google-Smtp-Source: AMrXdXt22k/H9K/mcGalzd49MEcMeKIHceeju0CKQ535fM4UXrGlS9mikhhf1z4gKZnEkys6hK9E X-Received: by 2002:aa7:842a:0:b0:581:8755:4953 with SMTP id q10-20020aa7842a000000b0058187554953mr27338950pfn.23.1672829283767; Wed, 04 Jan 2023 02:48:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672829283; cv=none; d=google.com; s=arc-20160816; b=e/d7XbEkGyWY5j6q6X3+z96VV4rkdkEABk3trDIvEp487grPe9874Lbh59wgZUPcqm 4u6tYHOf27+LbeZ1EkUN8K+KFK3rB0CcN0ZSmysDZ9zeGzE1jQaH+4DH48r+cOMQk++L HVPVAbOe6vhNv8Tl35kyH7XmcBdV3KsSrrqU4mtBj280yA5HA6zlcqlDG7sDlsbYTsk5 4CMAfDXM9AN7d+zOvzY8EM6B0fPs2W90ZkddrgeyqaKA5s4coCb/+Rf05FgwmVbN4gyD FxiuokXEDdSmquwZXbd+EXlTcr50AJvL5Zuayuy3U4mgqt+v0eM5DILctGWP2kesGCV5 JF9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=LJWDrSRhEFhfGsFyYK0V6BHpJWAjFj2NsvQbNJQkprs=; b=NyuvGXa1wVSJD6WShtSdpUKYjGJwGjyBxVlKYFYAB7u3NS9oa7x2eWKVXkiBpfnUmO mr4FAM/Nq0Lq0xivv74mMivU0Pk9T59RX0ieVLB5CUSSCmEUcjUl8Amf6cFNZIb17E1N 6eDuII5RkNWs1CLOVNxdRAn5/Gi7c8DGyvm1T1ilUxhyFqJyn3dUui+Smm0LbZ1CJsUQ YiHGJE8IN+YlsPT9P+mx6cBrUODo8lV/VRHpjkZVJFbOQTqVp+fdKzvfkdQggoToYVTE HrO5AU1LETacBjOh0+hRRbeYJ2X2TpksvWHdwq9TC2pDu2MoVc1+sCP66S5czvVGJnCC gc8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gJi0oHoP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p8-20020a056a000a0800b00580439e00fasi35656875pfh.45.2023.01.04.02.47.51; Wed, 04 Jan 2023 02:48:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gJi0oHoP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239068AbjADKqP (ORCPT <rfc822;tmhikaru@gmail.com> + 99 others); Wed, 4 Jan 2023 05:46:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234693AbjADKpy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 4 Jan 2023 05:45:54 -0500 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DFC813E0C for <linux-kernel@vger.kernel.org>; Wed, 4 Jan 2023 02:45:53 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id u28so43181898edd.10 for <linux-kernel@vger.kernel.org>; Wed, 04 Jan 2023 02:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=LJWDrSRhEFhfGsFyYK0V6BHpJWAjFj2NsvQbNJQkprs=; b=gJi0oHoP2yFg0MctdLdpqE2ESdF2cHoQkqWB66CMsRRLkx7Q4QcBm7En77HJmkBgFL Izg676PvTW3XeZPahl4WF8CF/bP+GLi9KfSdZh+ABN6xGgZlawamckeOJk4ph6cCN5PG 4i8B81JkqAThkZHqUJd26IiL1i4wbcNfWbzZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LJWDrSRhEFhfGsFyYK0V6BHpJWAjFj2NsvQbNJQkprs=; b=3w7ZLe54fsxW2RQpBSSX9iEP53+VIso04bg32Sw/o0PsLM/fxMAgtVULVgEI/qe29A N5kLnlGjMhvC+MJkMIgvY+/k8IgovA7nxd9so4Fh3dQm2JAHC6GIDT562YSdmKHabr4t VdIlX1J8nIR/WWpAQVP1gt8svhLKSuAroUvirDU4f1k3cd+oPkQaMstgxfvdGkTWceZZ ejt5ClVQCu5oC7aurz1tdb3d/dwrCLZ4cntstrKRHCcjW5nI9HWH88Wz7EEVrOMG6aRO T3h8eIwh6y438Hd/s8ILXLv7Kbzh2nSM28+LvMXPfEpASx1rxZ0ecZmH9iaNf6oBjJwS SGEQ== X-Gm-Message-State: AFqh2kq7Hc+q0inmrmJWxukW7p5UTMJQohYzbY2H7NY6xa77nIVQey1u odlLWQf8qwtPKMMeQSG0hsFMgA== X-Received: by 2002:a05:6402:3807:b0:47e:eb84:c598 with SMTP id es7-20020a056402380700b0047eeb84c598mr39079345edb.30.1672829152764; Wed, 04 Jan 2023 02:45:52 -0800 (PST) Received: from alco.roam.corp.google.com ([2620:0:1059:10:6531:9bb0:b3f7:86a8]) by smtp.gmail.com with ESMTPSA id g32-20020a056402322000b0048c85c5ad30sm4754971eda.83.2023.01.04.02.45.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jan 2023 02:45:52 -0800 (PST) From: Ricardo Ribalda <ribalda@chromium.org> Date: Wed, 04 Jan 2023 11:45:21 +0100 Subject: [PATCH v3 3/8] media: uvc: Create UVC_QUIRK_IGNORE_EMPTY_TS quirk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20220920-resend-hwtimestamp-v3-3-db9faee7f47d@chromium.org> References: <20220920-resend-hwtimestamp-v3-0-db9faee7f47d@chromium.org> In-Reply-To: <20220920-resend-hwtimestamp-v3-0-db9faee7f47d@chromium.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-kernel@vger.kernel.org, "hn.chen" <hn.chen@sunplusit.com>, Ricardo Ribalda <ribalda@chromium.org>, linux-media@vger.kernel.org X-Mailer: b4 0.11.0-dev-696ae X-Developer-Signature: v=1; a=openpgp-sha256; l=3974; i=ribalda@chromium.org; h=from:subject:message-id; bh=BJkG5vQwJjJAWQiYn2AnT8oOmSykPtFRv62ZOzP7kUA=; b=owEBbQKS/ZANAwAKAdE30T7POsSIAcsmYgBjtVjT3benz16nMI5QBuxLX89IhlFS3jj70mLziY7U 2sKTeoKJAjMEAAEKAB0WIQREDzjr+/4oCDLSsx7RN9E+zzrEiAUCY7VY0wAKCRDRN9E+zzrEiAA8D/ 49aOWCU5C/qlUPltX1KrAh75mVvc1R54PVqNns8jIVP6/vUO8mqFoeD0Ox3MdmyvrRQYoYp1Zh+tNV vHCmFS5HcDZd9IYDTQfQ6aFrstJS1pOhWO+vo5Ed9eksrydvvPYtjKfOj6KtW0SBL5MBzMe6iJIXrd TOotq9qlhu8B6n+L1C0fJbw3GOfjsW7KtdPV+HbpBEW9V5GUl0GeDY6tr+/b5mwq87gr4z++dpg7ig TbNOByRJXeI2An/RrUg+qhPlT3jhQszJcJYIvtR+4z0MZJqs+T1qo/10LybboyeL1GZGZoB8vFxQAa dwSPFPFmQTzckc99NivjZq+gwBQV/pex40z7Af7nwboemFTfWKhUMxI3inwV75qRsbADvBF8AZBq+o 7ATjhHfL5WCaq3/fia1wROy3yBAEdDmh2Yv+RHKBoG8y5/TW/oz2VcITIiDgRmu7ZOg66YkLQakjTv EIM1Jj+EDE509i/sX1lSnj5oz9I4gKGnSRdnA3/4CtkJ1ZHceN8+OgxHGzxps8P68MmKKL2TFos7fO Mg+kdIoo65ANupzDpmMCf/Cj6jE/yJF3FMyJprKtHgSiup8PalkiySFmkPfhoIk55WPY9h8TvZ2QcZ ZRNN3FlDieDn8JIBD82/sJeRDsLeZIg2X9cbre8Ey7R2tv524Ii1i/fwWZeA== X-Developer-Key: i=ribalda@chromium.org; a=openpgp; fpr=9EC3BB66E2FC129A6F90B39556A0D81F9F782DA9 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754088639004416927?= X-GMAIL-MSGID: =?utf-8?q?1754088639004416927?= |
Series |
uvcvideo: Fixes for hw timestamping
|
|
Commit Message
Ricardo Ribalda
Jan. 4, 2023, 10:45 a.m. UTC
Some SunplusIT cameras took a borderline interpretation of the UVC 1.5 standard, and fill the PTS and SCR fields with invalid data if the package does not contain data. "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 This borderline/buggy interpretation has been implemented in a variety of devices, from directly SunplusIT and from other OEMs that rebrand SunplusIT products. Luckily we can identify the affected modules by looking at the guid of one of the extension units: VideoControl Interface Descriptor: guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d} This patch adds a new quirk to take care of this. lsusb of one of the affected cameras: Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1bcf Sunplus Innovation Technology Inc. idProduct 0x2a01 bcdDevice 0.02 iManufacturer 1 SunplusIT Inc iProduct 2 HanChen Wise Camera iSerial 3 01.00.00 bNumConfigurations 1 Tested-by: HungNien Chen <hn.chen@sunplusit.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> --- drivers/media/usb/uvc/uvc_driver.c | 11 +++++++++++ drivers/media/usb/uvc/uvc_video.c | 10 ++++++++++ drivers/media/usb/uvc/uvcvideo.h | 1 + 3 files changed, 22 insertions(+)
Comments
Hi Ricardo, Thank you for the patch. On Wed, Jan 04, 2023 at 11:45:21AM +0100, Ricardo Ribalda wrote: > Some SunplusIT cameras took a borderline interpretation of the UVC 1.5 > standard, and fill the PTS and SCR fields with invalid data if the > package does not contain data. > > "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 > > This borderline/buggy interpretation has been implemented in a variety > of devices, from directly SunplusIT and from other OEMs that rebrand > SunplusIT products. > > Luckily we can identify the affected modules by looking at the guid of > one of the extension units: > > VideoControl Interface Descriptor: > guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d} > > This patch adds a new quirk to take care of this. > > lsusb of one of the affected cameras: > > Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc. > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.01 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > idVendor 0x1bcf Sunplus Innovation Technology Inc. > idProduct 0x2a01 > bcdDevice 0.02 > iManufacturer 1 SunplusIT Inc > iProduct 2 HanChen Wise Camera > iSerial 3 01.00.00 > bNumConfigurations 1 > > Tested-by: HungNien Chen <hn.chen@sunplusit.com> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > --- > drivers/media/usb/uvc/uvc_driver.c | 11 +++++++++++ > drivers/media/usb/uvc/uvc_video.c | 10 ++++++++++ > drivers/media/usb/uvc/uvcvideo.h | 1 + > 3 files changed, 22 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c > index 5448576a8413..c5ab6e2d24c3 100644 > --- a/drivers/media/usb/uvc/uvc_driver.c > +++ b/drivers/media/usb/uvc/uvc_driver.c > @@ -1199,6 +1199,17 @@ static const struct uvc_entity_quirk { > u8 guid[16]; > u32 quirks; > } uvc_entity_quirk[] = { > + /* > + * Some SunPlusIT uvc 1.5 device firmware expects that packages with > + * no frame data are ignored by the host. Therefore it does not clear > + * the PTS/SCR bits in the header, and breaks the timestamp decode > + * algorithm. > + */ > + { > + .guid = {0x82, 0x06, 0x61, 0x63, 0x70, 0x50, 0xab, 0x49, > + 0xb8, 0xcc, 0xb3, 0x85, 0x5e, 0x8d, 0x22, 0x1d}, > + .quirks = UVC_QUIRK_IGNORE_EMPTY_TS, > + }, > }; > > static void uvc_entity_quirks(struct uvc_device *dev) > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index def079c7a6fd..f469c62bedca 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -500,6 +500,16 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf, > if (len < header_size) > return; > > + /* > + * Some devices make a borderline interpreation of the UVC 1.5 standard s/interpreation/interpretation/ > + * and the packets with no data contain undefined timestamps. Ignore "and send packets with no data ..." ? > + * such packages to avoid interfering with the clock interpolation s/packages/packets/ > + * algorithm. > + */ > + if (stream->dev->quirks & UVC_QUIRK_IGNORE_EMPTY_TS && > + len == header_size) > + return; I've sent a reply to v2 which I'll copy here: Given that there may be no guarantee that the above GUID won't be used by devices that don't exhibit this problem, I'm wondering if we couldn't use a heuristics instead of a quirk. I'm thinking about something along the lines of if (buf->bytesused == 0 && len == header_size && has_scr && stc == 0 && sof == 0) This will catch suspicious SCR values (stc == 0 && sof == 0) on empty packets (len == header_size) sent before any data packet (buf->bytesused == 0), which should handle the devices you have to support, and avoid false positives (the stc == 0 && sof == 0 check is already quite restrictive, adding buf->bytesused == 0 would limit the workaround to packets before the first data packet). With this we could drop patch 2/8. > + > /* > * Extract the timestamps: > * > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h > index df93db259312..c3424ae29339 100644 > --- a/drivers/media/usb/uvc/uvcvideo.h > +++ b/drivers/media/usb/uvc/uvcvideo.h > @@ -74,6 +74,7 @@ > #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400 > #define UVC_QUIRK_FORCE_Y8 0x00000800 > #define UVC_QUIRK_FORCE_BPP 0x00001000 > +#define UVC_QUIRK_IGNORE_EMPTY_TS 0x00002000 > > /* Format flags */ > #define UVC_FMT_FLAG_COMPRESSED 0x00000001
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 5448576a8413..c5ab6e2d24c3 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1199,6 +1199,17 @@ static const struct uvc_entity_quirk { u8 guid[16]; u32 quirks; } uvc_entity_quirk[] = { + /* + * Some SunPlusIT uvc 1.5 device firmware expects that packages with + * no frame data are ignored by the host. Therefore it does not clear + * the PTS/SCR bits in the header, and breaks the timestamp decode + * algorithm. + */ + { + .guid = {0x82, 0x06, 0x61, 0x63, 0x70, 0x50, 0xab, 0x49, + 0xb8, 0xcc, 0xb3, 0x85, 0x5e, 0x8d, 0x22, 0x1d}, + .quirks = UVC_QUIRK_IGNORE_EMPTY_TS, + }, }; static void uvc_entity_quirks(struct uvc_device *dev) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index def079c7a6fd..f469c62bedca 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -500,6 +500,16 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf, if (len < header_size) return; + /* + * Some devices make a borderline interpreation of the UVC 1.5 standard + * and the packets with no data contain undefined timestamps. Ignore + * such packages to avoid interfering with the clock interpolation + * algorithm. + */ + if (stream->dev->quirks & UVC_QUIRK_IGNORE_EMPTY_TS && + len == header_size) + return; + /* * Extract the timestamps: * diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index df93db259312..c3424ae29339 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -74,6 +74,7 @@ #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400 #define UVC_QUIRK_FORCE_Y8 0x00000800 #define UVC_QUIRK_FORCE_BPP 0x00001000 +#define UVC_QUIRK_IGNORE_EMPTY_TS 0x00002000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001