Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp7314653rwl; Fri, 30 Dec 2022 06:50:51 -0800 (PST) X-Google-Smtp-Source: AMrXdXvavs+FujuSAUU9zLSCSiIk/rJWETRLi6Zv+s0JNTBq5zNTz4qDubsOH0Z0ro7gVxVePKq+ X-Received: by 2002:a17:907:c084:b0:7c1:22a6:818f with SMTP id st4-20020a170907c08400b007c122a6818fmr28162552ejc.25.1672411851241; Fri, 30 Dec 2022 06:50:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672411851; cv=none; d=google.com; s=arc-20160816; b=eZZSjTJRl7K4iIj8ys/tY5NPvDD+oz/ubQORjf1xJHvbh4UW7TUp0+jtcscGR3SGhB KPAbfQ3hYfzkZab1FmdTbc8rs+t3D5ZXIX04WyK81yKhNm+7xBDD9BdmBrnFRZN+I4uY iHzxlaW5TYxeUktDUQcnf0AHbgiSayWtZhJwq/YkkHB0YQF40vrc1nYcllQDzIHMHfu5 619WB8z68NDUso9qcd7pBNiDw7Y1QgL4NzuU9P0T4nLQUCjaGpgsHMpQ6utlwTY4uGNG G+Vyjd8QqmDeWBoEdN9yBPZb26o9D0FNd12K4zlMJuDKhftY4p4h3+q3YF0LUYyAmKrF ETxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=AkTGn59ZICecw26NKjZQtXkrlH1IcHCdZmDon5UNMro=; b=Z11gkBC5//HapuFRCwXN2AROKxPFz6jN8VnoF81rHptkXhOYMpJngBm30WkOxlpVAW ahfDl3vy3D0k9x5Ci89QFDHoVqdfeNyjhs5KZPBPVkF2R4t+0Oleth+XHODlG0OKzLa9 5eWcJMNqmANojFp5O5YkyKFp7t4ELvOLbbr7WMka66IPCwB7Bn5AKOGdaPnyQBbbyhHE j4IBcyz86GDFUcobW+p2xmfSAD8ABUXdtAMkRTr0z9hoOSK90NsoGuNT8AKT/fBryobS ceMBSL808x9z1f03RTXrJwfJ4sPv00t5jSmBXSky7zco0IEvg46udMzq0V3KQJ0T7Pk0 ddAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=Mw0goLIb; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sg13-20020a170907a40d00b007c09bc6a8bfsi19001769ejc.250.2022.12.30.06.50.35; Fri, 30 Dec 2022 06:50:51 -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 (test mode) header.i=@ideasonboard.com header.s=mail header.b=Mw0goLIb; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235054AbiL3OiB (ORCPT + 63 others); Fri, 30 Dec 2022 09:38:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbiL3OiA (ORCPT ); Fri, 30 Dec 2022 09:38:00 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 951591901E; Fri, 30 Dec 2022 06:37:57 -0800 (PST) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id E8D452F5; Fri, 30 Dec 2022 15:37:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1672411076; bh=XnXoPl0/oTF/xEWJsb6tZooAxDcN8WbanoTfny0E5lQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mw0goLIbKld12s8iBzuSOHgRhJKR7suovCSRb33Ato5970iSXCaXellDPX4scibeU td7SjRb4NjLYxI7SWI+mLuePiWLihxaBhuZaJAwsnHCF7ciUchkS1zSihq+Jn4PkKy Ob7RHN6EorzgzGxGkjnTXbsAHNME0v+1CiJO87/I= Date: Fri, 30 Dec 2022 16:37:51 +0200 From: Laurent Pinchart To: Ricardo Ribalda Cc: Mauro Carvalho Chehab , "hn.chen" , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND v2 6/8] media: uvcvideo: Allow hw clock updates with buffers not full Message-ID: References: <20220920-resend-hwtimestamp-v2-0-0d7978a817cc@chromium.org> <20220920-resend-hwtimestamp-v2-6-0d7978a817cc@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220920-resend-hwtimestamp-v2-6-0d7978a817cc@chromium.org> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ricardo, Thank you for the patch. On Fri, Dec 02, 2022 at 06:02:46PM +0100, Ricardo Ribalda wrote: > With UVC 1.5 we get as little as one clock sample per frame. Which means > that it takes 32 frames to move from the software timestamp to the > hardware timestamp method. > > This results in abrupt changes in the timestamping after 32 frames (~1 > second), resulting in noticeable artifacts when used for encoding. > > With this patch we modify the update algorithm to work with whatever > amount of values are available. This too makes me thing that we should *really* move this to userspace. It will but much easier to implement clock domain translation there, with a better precision. > Tested-by: HungNien Chen > Signed-off-by: Ricardo Ribalda > --- > drivers/media/usb/uvc/uvc_video.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index 75c32e232f5d..7c6448c6d706 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -742,10 +742,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream, > > spin_lock_irqsave(&clock->lock, flags); > > - if (clock->count < clock->size) > + if (clock->count < 2) > goto done; > > - first = &clock->samples[clock->head]; > + first = &clock->samples[(clock->head - clock->count) % clock->size]; > last = &clock->samples[(clock->head - 1) % clock->size]; > > /* First step, PTS to SOF conversion. */ > @@ -760,6 +760,14 @@ void uvc_video_clock_update(struct uvc_streaming *stream, > if (y2 < y1) > y2 += 2048 << 16; > > + /* > + * Have at least 1/4 of a second of timestamps before we > + * try to do any calculation. Otherwise we do not have enough > + * precission. s/precission/precision/ How did you determine 250ms was the right threshold ? > + */ > + if ((y2 - y1) < (256 << 16)) > + goto done; > + > y = (u64)(y2 - y1) * (1ULL << 31) + (u64)y1 * (u64)x2 > - (u64)y2 * (u64)x1; > y = div_u64(y, x2 - x1); > -- Regards, Laurent Pinchart