ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: Mauro Carvalho Chehab <mchehab@infradead.org>,
	Jonathan Cameron <jic23@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>, Rob Herring <robh+dt@kernel.org>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Sensors and similar - subsystem interactions, divisions, bindings etc.
Date: Thu, 28 Jul 2016 23:32:24 +0100	[thread overview]
Message-ID: <a610c627-c747-c29f-8f00-e44a18fea996@jic23.retrosnub.co.uk> (raw)
In-Reply-To: <20160728085846.63971233@recife.lan>

On 28/07/16 12:58, Mauro Carvalho Chehab wrote:
> Em Wed, 20 Jul 2016 22:18:11 +0100
> Jonathan Cameron <jic23@kernel.org> 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. 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.
Absolutely.  We can come up with some rule's of thumb to at least cut
down on the number of drivers getting written / pitched for totally
the wrong subsystem, but there are always going to be corner cases.
> 
> 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.
Becomes a case of whether we almost 'limit' devices by putting them
in a subsystem dictated by their usecase, or find a way to bridge
between subsystems so the common use case and interfaces are supported
but the more 'interesting' stuff is available underneath - possibly
for other uses.

> 
>> * Lots of random things we haven't seen yet.
I've already seen a few in this thread!

Jonathan
> 
> Thanks,
> Mauro
> 

  parent reply	other threads:[~2016-07-28 22:32 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20 21:18 Jonathan Cameron
2016-07-21  7:39 ` Hans Verkuil
2016-07-22 19:37   ` Jonathan Cameron
2016-07-28 16:50   ` Laurent Pinchart
2016-07-21 19:10 ` Mark Brown
2016-07-22  3:29 ` Guenter Roeck
2016-07-22  4:18   ` Torokhov
2016-07-22 19:01     ` Jonathan Cameron
2016-07-22 10:21   ` Mark Brown
2016-07-22 19:31   ` Jonathan Cameron
2016-07-23  2:29     ` Sebastian Reichel
2016-07-28 21:30   ` Lars-Peter Clausen
2016-07-28 22:39     ` Jonathan Cameron
2016-07-29  0:56     ` Guenter Roeck
2016-07-29  5:54       ` Jonathan Cameron
2016-07-22 12:04 ` Linus Walleij
2016-07-22 19:22   ` Jonathan Cameron
2016-07-28 16:46   ` Laurent Pinchart
2016-07-28 18:08     ` Lars-Peter Clausen
2016-08-02 19:55       ` Linus Walleij
2016-07-28 22:07     ` Jonathan Cameron
2016-08-02 19:50     ` Linus Walleij
2016-07-27  3:12 ` Vinod Koul
2016-07-28 11:58 ` Mauro Carvalho Chehab
2016-07-28 16:42   ` Laurent Pinchart
2016-07-28 22:09     ` Jonathan Cameron
2016-08-01 11:03       ` Laurent Pinchart
2016-07-29  7:28     ` Hans Verkuil
2016-08-01 11:47       ` Laurent Pinchart
2016-07-28 22:32   ` Jonathan Cameron [this message]
2016-07-28 16:39 ` Laurent Pinchart
2016-07-28 18:53   ` Lars-Peter Clausen
2016-07-28 19:46     ` Mark Brown
2016-07-31 17:47     ` Vinod Koul
2016-08-01 12:14     ` Laurent Pinchart
2016-07-28 22:26   ` Jonathan Cameron
2016-07-29  7:36     ` Hans Verkuil
2016-08-01 11:19     ` Laurent Pinchart
2016-07-28 19:12 ` Lars-Peter Clausen
2016-07-28 23:38 ` Alexandre Belloni
2016-07-29  6:04   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a610c627-c747-c29f-8f00-e44a18fea996@jic23.retrosnub.co.uk \
    --to=jic23@jic23.retrosnub.co.uk \
    --cc=jic23@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=mchehab@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox