Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface support

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 3 Sep 2017 18:50:01 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Mon, 28 Aug 2017 12:23:45 -0400
> William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> 
> > On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote:  
> > >On Mon, 31 Jul 2017 12:03:46 -0400
> > >William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> > >    
> > >> This patch adds support for the IIO generic counter interface to the
> > >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not
> > >> be affected by this patch; all changes are intended as supplemental
> > >> additions as perceived by the user.
> > >> 
> > >> IIO Counter Signals are defined for all quadrature input pairs
> > >> (A and B), as well as index input lines. However, IIO Counter Triggers
> > >> are not created for the index input Signals. IIO Counter Values are
> > >> created for the eight quadrature channel counts, and their respective
> > >> Signals are associated via IIO Counter Triggers.
> > >> 
> > >> The new generic counter interface sysfs attributes expose the same
> > >> functionality and data available via the existing 104-QUAD-8 device
> > >> interface. Four IIO Counter Value function modes are available,
> > >> correlating to the four possible quadrature mode configurations:
> > >> "non-quadrature," "quadrature x1," "quadrature x2," and "quadrature x4."
> > >> 
> > >> A quad8_remove function is defined to call iio_counter_unregister. This
> > >> function can be eliminated once a devm_iio_counter_register function is
> > >> defined.
> > >> 
> > >> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>    
> > >
> > >A good example.
> > >
> > >I think it does make it clear that we need to be very careful on how much of
> > >the interface is defined by freeform strings.  Even if we export other means
> > >of establishing the associations to userspace, the moment there are strings
> > >available giving them names, software will start to use those.
> > >
> > >May be fine but we need to be very careful.    
> > 
> > I would like to limit the amount of strings as well; the availability of
> > freeform strings has an unfortunate tendency to create situations where
> > different drivers form separate conventions for duplicate functionality.  
> 
> Absolutely.
> 
> > 
> > The reason freeform strings are available for the generic counter
> > interface is to provide the flexibility to support more complex classes
> > of counters. More specific counter class interfaces such as the future
> > quadrature counter interface will likely expose predefined constants
> > rather than allow drivers to create their own strings. In general
> > though, I believe your warning is a good word of caution and I'll keep
> > an eye on reducing the amount of freeform strings we allow.  
> 
> OK. That could work fine - we enforce the usage by review rather than
> code.
> > 
> > In truth, while this is a good example of how a driver would utilize the
> > generic counter interface with real hardware, it's not a perfect case
> > for quadrature counters in general. As you noticed, the dynamic aspects
> > of the generic counter interface are not needed by the 104-QUAD-8. The
> > future quadrature counter interface would be more fitting for the
> > 104-QUAD-8.
> > 
> > In addition, I may provide a dummy software counter driver in version 2
> > of this patchset to showcase and exemplify the functionality of the
> > generic counter interface more directly and aptly.  
> 
> That could be very useful.  An alternative would be to look at a simple
> device (if we can find one) and implement a userspace fake for it
> (similar to what Guenter has done with lots of hwmon devices).
> 
> That way we can play with a real driver against fake hardware and get
> the best of all possible worlds.  I've been meaning to look at doing this
> for various IIO drivers for a while (most complete for i2c devices I think).
> 
> As you might imagine I don't actually have that many parts (and most of them
> aren't connected to boards at any given time) so any form of emulation can be
> very helpful.
> 
> I'll see if I can dig up any interesting devices beyond the ones we
> already know are integrated in various SoCs.

A quick search turned up a few parts that might do the job as additional
test parts.

lsi ls7366r - spi encoder to count chip. 
www.lsisci.com  - lots of parts made by them...

The broadcom (now - been various people) hctl-2032 - parallel output
but otherwise, does basic counting index etc.

https://www.tindie.com/products/Renbotics/tinyqed/
looks quite cute... Just does it using at little micro to do the hard work.
(long dead as a product by the look of it though..) Easy to emulate perhaps
but none of the links work..

Another thought would be to do a quick fpga version of whatever we
fancy playing with and use that.  I can think of a few people to
ask if this would be useful (could do it myself, but low on time
for the next few months at least).

Jonathan

> 
> I think we really need say 2+ devices to justify decisions in the
> core code. I did the original IIO version against 3ish devices but
> that was more varied (and that wasn't nearly enough with hindsight!)
> 
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html