From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f193.google.com ([209.85.219.193]:40007 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727348AbeJRMbE (ORCPT ); Thu, 18 Oct 2018 08:31:04 -0400 Received: by mail-yb1-f193.google.com with SMTP id w7-v6so11326651ybm.7 for ; Wed, 17 Oct 2018 21:32:02 -0700 (PDT) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com. [209.85.219.169]) by smtp.gmail.com with ESMTPSA id y206-v6sm4973842ywg.57.2018.10.17.21.32.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Oct 2018 21:32:00 -0700 (PDT) Received: by mail-yb1-f169.google.com with SMTP id k132-v6so185705ybc.2 for ; Wed, 17 Oct 2018 21:32:00 -0700 (PDT) MIME-Version: 1.0 References: <20181017075242.21790-1-henryhsu@chromium.org> <13883852.6N9L7C0n48@avalon> <2355808.GKno8i6Ks9@avalon> In-Reply-To: <2355808.GKno8i6Ks9@avalon> From: Tomasz Figa Date: Thu, 18 Oct 2018 13:31:48 +0900 Message-ID: Subject: Re: [PATCH] media: uvcvideo: Add boottime clock support To: Laurent Pinchart , gwendal@chromium.org, amstan@chromium.org Cc: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote: > > Hi Tomasz, > > 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? > > > Generally, I'd see a V4L2_BUF_FLAG_TIMESTAMP_BOOTTIME flag being added > > and user space being given choice to select the time stamp base it > > needs, perhaps by setting the flag in v4l2_buffer struct at QBUF time? > > I would indeed prefer a mechanism specified at the V4L2 API level, with an > implementation in the V4L2 core, over a module parameter. If the goal is to > use the boottime clock for synchronization purpose, we need to make sure that > all drivers will support it correctly. Patching drivers one by one doesn't > really scale. Agreed. Best regards, Tomasz