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;
Date:   Sun, 10 Nov 2019 10:14:08 -0500
From:   William Breathitt Gray <vilhelm.gray@gmail.com>
To:     Jonathan Cameron <jic23@kernel.org>
Cc:     Fabien Lahoudere <fabien.lahoudere@collabora.com>,
        gwendal@chromium.org, egranata@chromium.org, kernel@collabora.com,
        Jonathan Corbet <corbet@lwn.net>,
        Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        Guenter Roeck <groeck@chromium.org>,
        Hartmut Knaack <knaack.h@gmx.de>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
        Lee Jones <lee.jones@linaro.org>,
        Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        Nick Vaccaro <nvaccaro@chromium.org>,
        linux-iio@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] counter: cros_ec: Add synchronization sensor
Message-ID: <20191110151408.GB3984@icarus>
References: <cover.1566563833.git.fabien.lahoudere@collabora.com>
 <d985a8a811996148e8cda78b9fe47bb87b884b56.1566563833.git.fabien.lahoudere@collabora.com>
 <20190826095612.7455cb05@archlinux>
 <8abbe9360938ab851d16c2c1494ba56034775823.camel@collabora.com>
 <6b50bdff184e6af664b7a61e0a8a2cddc5718f0a.camel@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6b50bdff184e6af664b7a61e0a8a2cddc5718f0a.camel@collabora.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Sep 24, 2019 at 04:20:51PM +0200, Fabien Lahoudere wrote:
> Hi all,
> 
> After some discussions and investigation, the timestamp is very
> important for that sync driver.
> Google team uses that timestamp to compare with gyroscope timestamp.
> 
> So the important data is timestamp and counter value is useless.
> Just the event of counter increment is important to get a timestamp.
> 
> In that case, my idea was to just use an IIO driver with a single
> channel with IIO_TIMESTAMP. We discuss this here and it seems
> controversial.
> 
> So my question to Jonathan is if we have a timestamp coming from the EC
> itself, can we consider this timestamp as a good IIO driver?
> 
> Any other idea is welcome, however Google team would like to manage
> only IIO drivers if possible.
> 
> Thanks

Jonathan,

Should the the timestamp from the EC be introduced as an IIO driver
using IIO_TIMESTAMP?

Since there is no corresponding EC Counter driver in the baseline right
now we don't have a conflict yet. If the EC timestamp is introduced as
an IIO driver then we should make any future EC Counter driver mutually
exclusive with the IIO driver in order to prevent any memory space
conflict. At that point we may deprecate the IIO driver and move the
timestamp functionality to the corresponding Counter driver.

That's assuming someone is interested in the Count component enough to
implement an EC Counter driver; otherwise, the IIO driver will serve
just fine if timestamp is the only data desired from this device.

William Breathitt Gray