From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 59DD7413 for ; Mon, 1 Aug 2016 11:03:24 +0000 (UTC) Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8686FA7 for ; Mon, 1 Aug 2016 11:03:22 +0000 (UTC) From: Laurent Pinchart To: Jonathan Cameron Date: Mon, 01 Aug 2016 14:03:20 +0300 Message-ID: <4941501.pcImWRQfCn@avalon> In-Reply-To: <8fee553b-de04-27c9-9c33-d578a1f3cca1@jic23.retrosnub.co.uk> References: <5222c3bb-d6b7-0ccc-bf9e-becf5046a37a@kernel.org> <1509685.ufIZn1R9J2@avalon> <8fee553b-de04-27c9-9c33-d578a1f3cca1@jic23.retrosnub.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: Zhang Rui , Rob Herring , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Sensors and similar - subsystem interactions, divisions, bindings etc. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, > >>>=20 > >>> This topic would be around the way the various subsystems interac= t, in > >>> the rough area of 'sensors' (I haven't yet had much of an issue w= ith > >>> subsystem crossing with output devices but maybe that's just over= the > >>> next hill!) > >>=20 > >> Yeah, there is a gray area here as devices become more complex. > >> So, I'm interested on such topic. > >>=20 > >>> 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 thermopi= le > >>> to a thermal camera? Smart fingerprint scanners etc. Gesture > >>> recognition sensors (effectively 9ish pixel cameras) > >>=20 > >> For devices that provide images somehow, I'd say that the best wou= ld be > >> to implement them as via the V4L2 API. > >=20 > > This requires defining what an image is. Furthermore, we very low i= mage > > 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 perform= ance > > issues. > > An interesting point I'd never thought about before. Funnily enough t= he > devices around this boundary that I've encountered have all been rela= tively > 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 sens= ors=20 (for instance https://globenewswire.com/news-release/2016/01/19/802804/= 0/en/Himax-Launches-Ultra-Low-Power-CMOS-Image-Sensor-for-Always-On-Com= puter-Vision-Applications.html) will also bring=20 interesting challenges. The frame rate won't be particularly high, but = the low=20 resolution will allow transmitting image data over I2C (or rather I3C, = a=20 faster I2C-compatible serial bus, see http://mipi.org/specifications/i3= c=E2=84=A0-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 su= bsystem > >> boundaries, and sometimes multiple APIs from different subsystems = is > >> needed. Also, it is not clear where such drivers would fit at the = Kernel > >> tree. > >>=20 > >> 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. > >>=20 > >>> * Lots of random things we haven't seen yet. --=20 Regards, Laurent Pinchart