Message-ID: <20170903185001.64df919e@archlinux>
Date:   Sun, 3 Sep 2017 18:50:01 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     William Breathitt Gray <vilhelm.gray@...il.com>
Cc:     knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
        benjamin.gaignard@...aro.org, linux-kernel@...r.kernel.org,
        linux-iio@...r.kernel.org
Subject: Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface
 support

On Mon, 28 Aug 2017 12:23:45 -0400
William Breathitt Gray <vilhelm.gray@...il.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@...il.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@...il.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.

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

Powered by blists - more mailing lists