Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3922583ybz; Mon, 20 Apr 2020 11:57:32 -0700 (PDT) X-Google-Smtp-Source: APiQypLb3GEXFS20Lrt5X4zYWDuWayVVCWQ04oQevNs/SaqGPgTxF85q9DZuKvglNnSHshV/dlY4 X-Received: by 2002:a50:f699:: with SMTP id d25mr15509929edn.244.1587409051933; Mon, 20 Apr 2020 11:57:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587409051; cv=none; d=google.com; s=arc-20160816; b=rapYNi+w3T2CJvpMf3EpjORH1CWCXQwl++G1PyPpvSBg6xM37O+U63kEnhlfbgDQwv i2LH1E9iq8yTorzZJqgEXjs7mDtbpLqONZGSxNLKZ/xZKAUfTv/3hvGuduP9J+K6BsEI 1ZzygiQjnWcliuce3V3L7wm2g6AGFZ8IHHuSE7irLeIhrjp8/lYlYetfLGFVsf5TnJZJ icNjJuUTaGbnVcjKA7HLyhh0ygeoF4d7M40YI+YMTjA/XjLIQnbFHw1OmStgUNyphUE1 X9AzvV3bNrYwEIdgaG42M2xFzN/Iq0DV6D/2QQvIFGJrBOhNXPANEy9CHjbtghonXXcb EldA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sS4YS2nlJ10xkXGmMzOy7jMGWrIlLM0vLffgB5tHhvw=; b=jUvuaUxQj/iVfe9MIbcfDLli9m2CPU9TyBC3ekb1FNWDxJXBWcPyoNVmmfqw5t9Qms GnZABC9S/qBu5gAY967deiJqHB6ZYLQF89nOOw1rO3Q6i8IHLspYgvGzFhyVg/Nax6MX BeC6nd+rva8N5V/cSh4v+x8xNrMV50qp3jcZpqQ8tvZSdwVIhiy7u96GzptNCIvkpVwj PjJjOedBHF0thliAO+WEeqfLiBD9wsWRRT5iWmDfIkgGR8RgLwtmLx3Rgkzg+e6ufPEC rlkjjVSr4F347fmM/OSWlB3W82vXsQQ/Ixax7Kh1O8eZWoBPCxc/fjP75JIkK+P1v2bS mNcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=U1UVPdXM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r24si199950edm.269.2020.04.20.11.57.08; Mon, 20 Apr 2020 11:57:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=U1UVPdXM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726947AbgDTSy2 (ORCPT + 99 others); Mon, 20 Apr 2020 14:54:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726850AbgDTSy2 (ORCPT ); Mon, 20 Apr 2020 14:54:28 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAE36C061A0F for ; Mon, 20 Apr 2020 11:54:27 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id u189so6339309ilc.4 for ; Mon, 20 Apr 2020 11:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sS4YS2nlJ10xkXGmMzOy7jMGWrIlLM0vLffgB5tHhvw=; b=U1UVPdXMQxck81iz4E9kfwVW/WHaF+jXQmb23OmsK2DtqmBRTlEGOSYmWQjag5K5gb YM3qRvf52nmsT+0gO8oiB6foiANGTqwGioB9RKe+xH3k8P23jLzkVbwo2uwh3JGl9+ra NXFyZV8dOv+8azYRNM7Uw5YLdug3rmD0pjCI8= 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=sS4YS2nlJ10xkXGmMzOy7jMGWrIlLM0vLffgB5tHhvw=; b=GmHFRaO8Mr95qvuooK/Bn6fK1LSQNnwdm1JirIuZa5d9tlD77hvD7oapFpjwfR7v4I yAOb7UEYb3pijGLu8Sop9qB3zMBWVQ3gzFmEhbV2HMREJZTRnc6tLaVjPnmmLup/VO20 AeM1WuD7nEZciftsF4XIC/0VXPomPBLFD9UFIHpgg6Tyd5QZ32B8AL2nygXGUuV2Ne9S g8NnNuOyftZDCyseHrxRlHW1cly5lPI68O2qTw0X0pmtPL8tmGMz1/9uNFhMWLGmJxzc H+224sgfAPVKB2Z5u3DyH9kXfdqnfiUfHaAiMEXNAVdGRU9mZAP7V/Lhz+POf46cCLLn MwhA== X-Gm-Message-State: AGi0PuYjpcjPFPnM8s+PbXJdWe01Ielim3zdOtMFB9rpmQ0rH59S1/M9 8v7x3rb7rNBJX3lZeFxnTBwj1c0zkOZG2+SLo6xt2w== X-Received: by 2002:a05:6e02:544:: with SMTP id i4mr3464318ils.145.1587408867241; Mon, 20 Apr 2020 11:54:27 -0700 (PDT) MIME-Version: 1.0 References: <20200413195514.192868-1-gwendal@chromium.org> <20200414204814.GH7347@icarus> In-Reply-To: <20200414204814.GH7347@icarus> From: Gwendal Grignou Date: Mon, 20 Apr 2020 11:54:16 -0700 Message-ID: Subject: Re: [PATCH v2] drivers: counter: Add Cros EC Sync counter To: William Breathitt Gray Cc: Enric Balletbo i Serra , Jonathan Cameron , Benson Leung , Guenter Roeck , linux-kernel , linux-iio 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 Tue, Apr 14, 2020 at 1:48 PM William Breathitt Gray wrote: > > On Mon, Apr 13, 2020 at 12:55:14PM -0700, Gwendal Grignou wrote: > > When the camera vsync pin is connected to the embedded controller (EC) of > > a chromebook, the EC reports a sensor with a counter that increases > > at each GPIO rising edge. > > > > The sensor is presented using the counter subsystem. > > In addition, it is also presented via the IIO subsystem with a timestamp, > > allowing synchronisation with sensors connected to the same EC, for > > image stabilisation or augmented reality applications. > > Hi Gwendal, > > Sorry for the delay. I have some changes requested below. > > > To enable the counter: > > via counter ABI: > > echo "rising edge" > counterX/count0/signal_action > > via iio ABI > > echo 1 > iio:deviceY/en > > > > To disable the counter: > > via counter ABI: > > echo "none" > counterX/count0/signal_action > > via iio ABI > > echo 0 > iio:deviceY/en > > Although in theory a user could manually disable the actions for a > Signal, this is a very roundabout way of actually disabling the Count. > It's better to expose an "enable" attribute to allow the users to > perform this functionality; for example: > > echo 0 > counterX/count0/enable > echo 1 > counterX/count0/enable > > > > > To read the current counter value: > > via counter ABI: > > cat counterX/count0/count > > via iio ABI > > cat iio:deviceY/in_count_raw > > I know we discussed this in the last review but it's still the same as > before: IIO_COUNT interface is deprecated so new drivers won't be > allowed to use it. You'll have to remove the IIO_COUNT code in this > driver and replace it with Counter subsystem equivalents. I understand the need of a clean separation between counter and IIO subsystems. I will wait for counter to offer a way to gather timestamp'ed counts. Do you have a plan/proposed ABI you can share? Thanks, Gwendal.