Re: [Ksummit-discuss] [TECH TOPIC] Sensors and similar - subsystem interactions, divisions, bindings etc.

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Linus,

On Friday 22 Jul 2016 14:04:07 Linus Walleij wrote:
> On Wed, Jul 20, 2016 at 11:18 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> > This topic would be around the way the various subsystems interact, in the
> > rough area of 'sensors' (I haven't yet had much of an issue with subsystem
> > crossing with output devices but maybe that's just over the next hill!)
> > 
> > Scope may well be wider but includes:
> > * input (some of it)
> > * hwmon
> > * iio
> > * comedi(?)
> > * thermal
> > * power/battery
> > * gpio - the blur between gpios and beaglescope / PLC type I/O.
> 
> I'm in. The new chardev ABI was designed to fit play/well with IIO,
> for example I added a 64bit timestamp also to GPIO events so that
> people could do what I guess they refer to as sensor fusion mixing
> and blending sensor input events with GPIO events.
> (https://en.wikipedia.org/wiki/Sensor_fusion)
> 
> What I wanted to bring up ASAP was when I noticed in linux-next
> commit bc2b7dab629a51e8beb5fda4222c62a23b729f26
> "iio:core: timestamping clock selection support"
> that we should probably move this code to e.g. drivers/base
> or drivers/lib so I can reuse the same ABI in sysfs for
> GPIO event timestamping.
> 
> I think timestamping events uniformly is something that is
> important to all userspaces.
> 
> > Dmitry and I often have to decide on the IIO / input scope boundary
> > (and we've moved it over time) + a number of cross over drivers have
> > turned up recently.
> 
> (snip from elsewhere)
> 
> > Is it ever sensible to have two drivers for the same part because
> > the use cases are so different? (I hope there is always a better way
> > but maybe not)
> 
> I have one on my knee as I want to make a proper IIO driver
> for MPU-3050 gyroscope which has a (very simplified) driver in
> drivers/input/misc/mpu3050.c that was merged before the advent
> of the IIO subsystem.
> 
> For the new driver I have these options:
> 
> - Keep both drivers and consider them for different usecases.
>   of the same hardware that require different Kconfig (seems
>   very unelegant to me)
> 
> - Add some input event calls into the IIO driver so we can
>   phase over the older uses to the new driver.
> 
> - Drop the input event handling since gyroscopes should not
>   be handled by input anyway
> 
> - Develop a generic IIO-gyroscope-to-input event bridge.
>   (Phew seems complex.)
> 
> (elsewhere)
> 
> > IIO-input has been partly held outside mainline for years by this issue.
> 
> Is there such a thing? gitweb?
> 
> > 1) Are we happy with the somewhat adhoc divisions of subsystems as they
> > stand?
> 
> IETF has this motto "rough consensus and running code", and
> for me that is the working assumption to most things
> driver-subsystem-division-of-responsibilities-related.
> 
> > We have had quite a few cases where a whole driver is submitted to the
> > 'wrong' subsystem. Not the best first interaction with the kernel
> > world for new contributors. (This sort of area is attracts newbies
> > as it's relatively simple and the hardware is fairly cheap and more
> > than once their first experience with review as exactly this!)
> 
> What is sometimes lacking is users who are clever enough to
> take the latest kernel (or preferably even -next) and git grep for
> a few strings related to the hardware they want to support, and
> be revealed the fact that there is already a driver for it.
> 
> If there isn't, their problem is that of finding the right subsystem
> to pigeon-hole their hardware into. It typically requires a kernel
> old grumpy person saying "no, THIS thing goes THERE, THAT
> thing goes THERE". Unfortunately I think this is pretty hard to
> codify.
> 
> > If we aren't happy, what do we do about it?
> 
> More helpful kernel generalists...
> 
> > GPIO is another interesting case - a lot of hardware is capable of
> > parallel sampling, some at high speeds. It's another area that
> > is probably too specialist for this discussion, but if people want
> > to dive into the details it might be interesting.
> 
> I currently have (for v4.8) an ABI which makes i possible to e.g.
> read 32 simultaneous lines with one userspace/kernelspace
> swap, if it ends up as a readl() from a register.
> 
> The userspace ABI has a limitation to 64 values, so it would be
> possible to have some driver read 64 GPIO lines and return them
> in a u8 vector back to userspace in one go.
> 
> For an oscilloscope or signal analyzer usecase with more than
> 64 channels needing to be sampled simultaneously, we may need
> to add another "large GPIO read" ABI, and also probably a new
> driver API interface to achieve it. I've never seen hardware that can
> read more values in parallel than 32 though, I chose 64 to get some
> headroom.

Such a use case would put strong real-time constraints on the system, I wonder 
how useful a GPIO-based signal analyzer would be. Are you aware of any GPIO 
hardware that can be programmed to sample at a precise point in time (or 
perhaps even periodically) ?

> > Linus Waleij (gpio)
> 
> Sure, if travels etc work out and I get invited I'd come running.

-- 
Regards,

Laurent Pinchart