From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AEFCC433DF for ; Mon, 8 Jun 2020 14:09:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 447712072F for ; Mon, 8 Jun 2020 14:09:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729832AbgFHOJJ (ORCPT ); Mon, 8 Jun 2020 10:09:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726092AbgFHOJI (ORCPT ); Mon, 8 Jun 2020 10:09:08 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 231AAC08C5C2; Mon, 8 Jun 2020 07:09:08 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jiISS-00083D-MF; Mon, 08 Jun 2020 16:09:00 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 22334100F9F; Mon, 8 Jun 2020 16:09:00 +0200 (CEST) From: Thomas Gleixner To: Sean Nyekjaer , Lorenzo Bianconi , linux-kernel , "Rafael J. Wysocki" , Alexandre Belloni Cc: linux-iio Subject: Re: IIO timestamp get skewed when suspending (st_lsm6dsx) In-Reply-To: References: <20200603080619.GA544784@lore-desk.lan> <91165f5d-8cba-3ea2-67dc-99d65bce3d19@geanix.com> <20200603102841.GC544784@lore-desk.lan> <20200603105105.GD544784@lore-desk.lan> <20200603121227.GE544784@lore-desk.lan> <55fb09cf-76ab-0c42-7283-0836838f2deb@geanix.com> <20200603125630.GF544784@lore-desk.lan> <2d60c115-a634-c25f-b50b-38f13cac6229@geanix.com> <20200603134033.GG544784@lore-desk.lan> <2d8b2b9b-5e63-1254-04d9-8b9be0d91877@geanix.com> Date: Mon, 08 Jun 2020 16:09:00 +0200 Message-ID: <87k10habur.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean, Sean Nyekjaer writes: > I have a question regarding CLOCK_REALTIME and CLOCK_BOOTTIME when > resuming from suspend. > > We have run into problems with > drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c + the first patch from > Lorenzo Bianconi in this thread. The accelerometer have an internal > FIFO that includes a timestamp. When we resume from suspend, the > driver resets the fifo ts counter and sets an internal reference to > that time. > > But to me it looks like both CLOCK_REALTIME and CLOCK_BOOTIME aren't > ready when st_lsm6dsx_resume() is called. That depends on your system. Timekeeping is resumed way before drivers are resumed, but the suspend time injection might happen late when there is no early device to read from. In this case it happens when the RTC is resumed. If the IIO driver resumes before the RTC which injects the suspend time, then the core time is still in the past. And RTC is using the default resume mechanism, so depending on device/class registration order this might be the case. Deferring to the PM & RTC wizards. Thanks, tglx