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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 84071C433DF for ; Fri, 14 Aug 2020 09:32:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 60F3D20639 for ; Fri, 14 Aug 2020 09:32:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JJDdYGX+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726701AbgHNJcD (ORCPT ); Fri, 14 Aug 2020 05:32:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726270AbgHNJcD (ORCPT ); Fri, 14 Aug 2020 05:32:03 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0ED2C061383; Fri, 14 Aug 2020 02:32:02 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id e4so4151889pjd.0; Fri, 14 Aug 2020 02:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c8WGCCyt5Nm84cGuy3CE7BJ5TpGDOMgackC8NG3DTSU=; b=JJDdYGX+qYWom1+glsIFm36aA+kq05sY4IHY19GWFo+PrPtxaUl35YPoR0IJY/5Ogd ZFILUD2en5qve9Ofuic2q48oR+QRvlJ+IlACLTFByvGEw7aVUMkVBQKMLB7uEKGX2p/4 vWnrNhJ1JVT+wZ6osS2ym6Bg+XH3m2sxY3hLKiJq2ZqnD4ltGJV0xL8D/bZfxqrIjp7N hZTCUCuAjkErf2jD4WXLl5TwnKF3PgmNMC+kBpnz/SVfbWhO7478X3srdWobHCmQLQv0 jk4pajJTDcww3t59abFNjK+WArkTvBuYPLQsQg8YcTmBN2MtUfgHxDjvRGEwOr84tt6i nT0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c8WGCCyt5Nm84cGuy3CE7BJ5TpGDOMgackC8NG3DTSU=; b=HHFQwGRn7qP87yGxF+/OA8sq5UyRRbmTVcNHslRtGM9GO5pBCYLq+3hBZ5XWPoMLSw zEiPS4Y6Ko7a9Zjb9ClcT3Zr/12i7wqdxEM6g78HM362RIdWEZIFa8i/7UkIcNPgEx1j kmh4D1CjEg0O9KLTUkr9o1eiykvWESBXz+anOkA7pUV7AKFQbihGfqeNsBDEKKZKpTzS xlIP0WlHoyuizb6qxTpiisR772r4cSvBqH0TurGhGYbeqSXhdX6SO+sstyGj5EmY5ACJ egsnebTdm/thuTZkBQVSa71zs58hGIudrPbFpojZFMErtmtlI915Y0pWQvfkfZICiGJF 6x0Q== X-Gm-Message-State: AOAM530/mhhOF/gcw1XH1kjItGS1R2T9GbzZoLuL9paSsPVFEkzsPIaT TsfSJ6OKmK3b8aKYqR+XDQQ1HXYy1S4SJrLM7viUyzhIccpCNA== X-Google-Smtp-Source: ABdhPJx6uFRSOQ3rT9bgL2A99Me+ZV3uK5yhchrCJk0lDm2umwqxrGruDGfbhtHqO6DMgZiJWrbvLR0PHRJlo4UIs/g= X-Received: by 2002:a17:90a:bc41:: with SMTP id t1mr1471976pjv.181.1597397522294; Fri, 14 Aug 2020 02:32:02 -0700 (PDT) MIME-Version: 1.0 References: <20200813075125.4949-1-cmo@melexis.com> <20200813075125.4949-4-cmo@melexis.com> In-Reply-To: From: Andy Shevchenko Date: Fri, 14 Aug 2020 12:31:46 +0300 Message-ID: Subject: Re: [PATCH v5 3/5] iio:temperature:mlx90632: Convert polling while loop to do-while To: Crt Mori Cc: Jonathan Cameron , linux-iio , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 14, 2020 at 10:33 AM Crt Mori wrote: > On Thu, 13 Aug 2020 at 21:41, Andy Shevchenko wrote: > > On Thu, Aug 13, 2020 at 4:04 PM Crt Mori wrote: > > > On Thu, 13 Aug 2020 at 13:24, Andy Shevchenko wrote: > > > > On Thu, Aug 13, 2020 at 2:14 PM Crt Mori wrote: > > > > > On Thu, 13 Aug 2020 at 13:03, Andy Shevchenko wrote: > > > > > > On Thu, Aug 13, 2020 at 10:53 AM Crt Mori wrote: > > > > ... > > > > > > > > I don't see how it prevents using iopoll.h. It uses usleep_range() > > > > > > under the hood in the same way you did here, but open coded. > > > > > > > > > > > > > > > > One loop is indeed 10ms and that is not the problem, the problem is > > > > > that timeout is at least 3 calls of this data ready (3 channels), so > > > > > that is at minimum 30ms of timeout, or it could even be 4 in worse > > > > > case scenario and that is outside of the range for usleep to measure. > > > > > So in case of the other loop, where we wait 200ms for channel refresh > > > > > it is also out of scope. Timeout should be in number of tries or in > > > > > msleep range if you ask me. > > > > > > > > I still didn't buy it. You have in both cases usleep_range(). Why in > > > > your case it's okay and in regmap_read_poll_timeout() is not? > > > > > > > > > > I tried and it did not work, so then I read the manual. Looking into > > > > > > * regmap_read_poll_timeout_atomic - Poll until a condition is met or a > > > timeout occurs > > > > Why _atomic?! > > I just pasted something, it is the same as for non _atomic OK. ... > > > * @delay_us: Time to udelay between reads in us (0 tight-loops). > > > * Should be less than ~10us since udelay is used > > > * (see Documentation/timers/timers-howto.rst). > > > * @timeout_us: Timeout in us, 0 means never timeout ... > > > > > > > usleep_range(10000, 11000); > > > > You use here usleep_range(). The same is used for > > regmap_read_poll_timeout(). What's the difference? > > > > Since it uses 1/4 of the range you probably need to update tries and > > timeout_us to make it work. > > > > Timeout_us here needs to be in one case 100 * 10ms (maybe not > realistic as we could live with number of around 40 * 10ms), but this > is a lot more than proposed range of usleep which Is up to 20ms. Even > in best case this timeout should be 40 ms to give enough time to > measure 2 channels for sure. So with the current timeout_us > requirement we are outside of the range of the udelay timer and that > is why I would need a macro with number of tries, not with the timeout > value (or timeout value of ms). I do not understand. The regmap_read_poll_timeout() is a macro which unrolls in the very similar loop you have now in the code. What prevents it from using it? I think there is a big misunderstanding about the parameters of that macro. delay_us (must be small enough), timeout_us can be any long. -- With Best Regards, Andy Shevchenko