On Sun, 10 Nov 2019 10:14:08 -0500 William Breathitt Gray <vilhelm.gray@xxxxxxxxx> wrote: > 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? It is is a rather odd driver but I suppose it would be fine with lots of clear docs on why it is how it is... > > 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 route does become somewhat of a mess so I suspect we'd have to have a single driver supporting both userspace interfaces. If you are happy that we'd be adding a bit of legacy to support for ever then we can go that way. > > 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
