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

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

On Thursday 28 Jul 2016 23:09:59 Jonathan Cameron wrote:
> On 28/07/16 17:42, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 08:58:46 Mauro Carvalho Chehab wrote:
> >> Em Wed, 20 Jul 2016 22:18:11 +0100 Jonathan Cameron escreveu:
> >>> Hi All,
> >>> 
> >>> 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!)
> >> 
> >> Yeah, there is a gray area here as devices become more complex.
> >> So, I'm interested on such topic.
> >> 
> >>> 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.
> >>> * v4l - when does a device jump from being a multi pixel thermopile
> >>> to a thermal camera? Smart fingerprint scanners etc.  Gesture
> >>> recognition sensors (effectively 9ish pixel cameras)
> >> 
> >> For devices that provide images somehow, I'd say that the best would be
> >> to implement them as via the V4L2 API.
> > 
> > This requires defining what an image is. Furthermore, we very low image
> > resolution devices, we will need to deal with high frame rates (1k-10k is
> > a range we need to consider). The V4L2 API will likely show performance
> > issues.
>
> An interesting point I'd never thought about before. Funnily enough the
> devices around this boundary that I've encountered have all been relatively
> slow. Doubt we'll be lucky enough that that will last!

For the sake of completeness, I'd like to add that always-on image sensors 
(for instance https://globenewswire.com/news-release/2016/01/19/802804/0/en/Himax-Launches-Ultra-Low-Power-CMOS-Image-Sensor-for-Always-On-Computer-Vision-Applications.html) will also bring 
interesting challenges. The frame rate won't be particularly high, but the low 
resolution will allow transmitting image data over I2C (or rather I3C, a 
faster I2C-compatible serial bus, see http://mipi.org/specifications/i3c℠-sensor-specification) in a continuous fashion.

> >> We'll likely need to discuss it case by case, specially for early cross-
> >> subsystem drivers, though, as it is not trivial to identify the subsystem
> >> boundaries, and sometimes multiple APIs from different subsystems is
> >> needed. Also, it is not clear where such drivers would fit at the Kernel
> >> tree.
> >> 
> >> One interesting case is an input device driver with multi-finger
> >> support (drivers/input/touchscreen/sur40.c). I suspect we'll have
> >> more cases like that over time.
> >> 
> >>> * Lots of random things we haven't seen yet.

-- 
Regards,

Laurent Pinchart