Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp892280imd; Thu, 1 Nov 2018 07:12:10 -0700 (PDT) X-Google-Smtp-Source: AJdET5cnB4A+fTeK4zan6FLU7l1f3VjtMAWTK9h/QxINO7r1XNOGwD5Jv5OjWS7DSV5wdwtMIlKa X-Received: by 2002:a63:7d05:: with SMTP id y5-v6mr7283700pgc.171.1541081530735; Thu, 01 Nov 2018 07:12:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541081530; cv=none; d=google.com; s=arc-20160816; b=0VWtx4K/kiTSv4e95TRT6cX84zni9YbTbAw0zTJ3gSf+rAjVGtC5r2xsKqsbW+UjtD 0jpGKtXSFNcuUmQpllbQ6obGI6qRvZjKyBVZ2Y1vTs1CtN9m2usPUiyMbfK3MUsDFG93 MON7gzC8YmJSYYM/2/rfl4jiNZsJBcTRPtcAwH/1W3Gypa44mHzGEqcPpYmQPDR2SquL qkCChvwjb5cMZ34PT9xw9LTJ5UIdFtDfAiPwgSqGmZM6icOBtA+wlpRPAw+pOUYMwDXH MXHFKbSwHeMmTug2YOKQppW0+OdQPzOq8uzxp6OiZN3qKAfA2lZ3N6pEmBbuMhPM1wzD JjXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:dkim-signature; bh=GdvH6FlgxhxvujgozW3HiUWiAm3DN5I8BqGj5bvekkw=; b=ZJvH0ABa4IrR612sGSA4SrMKnbh2O4d9VecuZ7wU1lLwy7h3Xym3+LFx2FlznvONnK MdVS427NPtavrEX4OaThjR6YTT4Q+N9MD7oZIU0Az+AhgSi3pdCZaAUM6oDRPE+OTZKc 3utpRBrYASMA5qVau3n1FXDSgPi71ZffryA329JoB3r2fhkfaQ/QHMm+EVH6fVzlzChG Oj199omBBjbCs3DZj+/8DoOgs0kGf2VuKo75+t3W2RTbMSdkmfQw+2kWGwenFy1OxuPj uF5nVNX4brPHIS4BCHeDnx+Mv+ubpemyqFUhwQ11s19gr+RjmmvwY4ppTC6s5Ak224um uIdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=C6SxzlUn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 91-v6si31657698ply.48.2018.11.01.07.11.54; Thu, 01 Nov 2018 07:12:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=C6SxzlUn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728717AbeKAXGY (ORCPT + 99 others); Thu, 1 Nov 2018 19:06:24 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:47568 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727950AbeKAXGY (ORCPT ); Thu, 1 Nov 2018 19:06:24 -0400 Received: from avalon.localnet (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9B3CD1A4A; Thu, 1 Nov 2018 15:03:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1541080996; bh=zaT1pmresa1QQmLvqr6CailAvuL3uXlAIjGx29RqMek=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C6SxzlUnda2Qhz/arc8iL7+YkqP7VTS/JWaQah/q+W72HS5YkKU5bt3zg4QRDI7d6 Hdv0NTdfg8pKBDHdTfV9z+pm0ji/Dc2VmSIKmYLXfCzPOeM9pdd2iAyTseYBzFi+9k 9Yj/LDiafBkklYg2Vl4bdBi2Z3EFalujGzTtJMEc= From: Laurent Pinchart To: Alexandru M Stan Cc: Tomasz Figa , Gwendal Grignou , Heng-Ruey Hsu , Mauro Carvalho Chehab , Linux Media Mailing List , Linux Kernel Mailing List , Ricky Liang , linux-iio@vger.kernel.org, Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler Subject: Re: [PATCH] media: uvcvideo: Add boottime clock support Date: Thu, 01 Nov 2018 16:03:22 +0200 Message-ID: <1610184.U7oo9Z4Yep@avalon> Organization: Ideas on Board Oy In-Reply-To: References: <20181017075242.21790-1-henryhsu@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexandru, On Thursday, 18 October 2018 20:28:06 EET Alexandru M Stan wrote: > On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote: > > On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote: > >> On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote: > >>> On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote: > >>>> On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote: > >>>>> Android requires camera timestamps to be reported with > >>>>> CLOCK_BOOTTIME to sync timestamp with other sensor sources. > >>>> > >>>> What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If > >>>> the monotonic clock has shortcomings that make its use impossible for > >>>> proper synchronization, then we should consider switching to > >>>> CLOCK_BOOTTIME globally in V4L2, not in selected drivers only. > >>> > >>> CLOCK_BOOTTIME includes the time spent in suspend, while > >>> CLOCK_MONOTONIC doesn't. I can imagine the former being much more > >>> useful for anything that cares about the actual, long term, time > >>> tracking. Especially important since suspend is a very common event on > >>> Android and doesn't stop the time flow there, i.e. applications might > >>> wake up the device to perform various tasks at necessary times. > >> > >> Sure, but this patch mentions timestamp synchronization with other > >> sensors, and from that point of view, I'd like to know what is wrong with > >> the monotonic clock if all devices use it. > > > > AFAIK the sensors mentioned there are not camera sensors, but rather > > things we normally put under IIO, e.g. accelerometers, gyroscopes and > > so on. I'm not sure how IIO deals with timestamps, but Android seems > > to operate in the CLOCK_BOTTIME domain. Let me add some IIO folks. > > > > Gwendal, Alexandru, do you think you could shed some light on how we > > handle IIO sensors timestamps across the kernel, Chrome OS and > > Android? > > On our devices of interest have a specialized "sensor" that comes via > IIO (from the EC, cros-ec-ring driver) that can be used to more > accurately timestamp each frame (since it's recorded with very low > jitter by a realtime-ish OS). In some high level userspace thing > (specifically the Android Camera HAL) we try to pick the best > timestamp from the IIO, whatever's closest to what the V4L stuff gives > us. > > I guess the Android convention is for sensor timestamps to be in > CLOCK_BOOTTIME (maybe because it likes sleeping so much). There's > probably no advantage to using one over the other, but the important > thing is that they have to be the same, otherwise the closest match > logic would fail. That's my understanding too, I don't think CLOCK_BOOTTIME really brings much benefit in this case, but it's important than all timestamps use the same clock. The question is thus which clock we should select. Mainline mostly uses CLOCK_MONOTONIC, and Android CLOCK_BOOTTIME. Would you like to submit patches to switch Android to CLOCK_MONOTONIC ? :-) -- Regards, Laurent Pinchart