All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: 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: Wed, 27 Jul 2016 08:42:53 +0530	[thread overview]
Message-ID: <20160727031253.GV9681@localhost> (raw)
In-Reply-To: <5222c3bb-d6b7-0ccc-bf9e-becf5046a37a@kernel.org>

Hi Jonathan,

On Wed, Jul 20, 2016 at 10:18:11PM +0100, Jonathan Cameron wrote:
> 
> 5) Complex device interaction usecases.  At the moment the ones I've come
> across are mostly contained in IIO.  The moment we start sticking in
> MUXes, AFEs (Analog Front Ends) and straightforward analog sensors in the
> mix it can get fiddly.  Swapping war stories may well be worthwhile on
> this. This stuff also turns up in ASoC for example so probably lessons
> to be learned from there.
> 
> The analog devices software defined radios are another possible case
> study.
> 
> There of course may well be lessons to be learned from similar
> interactions elsewhere in the kernel.
> 
> There is a lot of history in how we ended up where we are (it all made
> absolute sense at the time). Sitting back and taking the time
> to discuss the future would be great.  Whilst this might be solvable
> by email we've made no definitive progress for years
> (and what has been made has been on a case by case basis deep in
> driver reviews.)
> 
> I threw comedi in the list above but, at the moment, I think the more
> likely direction there is a single userspace library abstracting
> the underlying subsystem (Analog Devices are working in that
> direction - perhaps Lars can offer more on that?).
> 
> 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 think we have only a small amount of fuzz around the v4l boundary,
> but wanted to leave the door open if anyone wants to discuss that
> one further as it's come up a few times over recent years.
> 
> The SoC world is a major case of one device, many uses.  Some SoCs
> are turning up with multiple ADC units, sometimes with different
> designs, sometimes simply so that the same hardware can be used for different things.

I would be interested in this discussion. Complex device seem to be getting
more complex over here as well!

Thanks
-- 
~Vinod

  parent reply	other threads:[~2016-07-27  3:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20 21:18 [Ksummit-discuss] [TECH TOPIC] Sensors and similar - subsystem interactions, divisions, bindings etc 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 [this message]
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
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=20160727031253.GV9681@localhost \
    --to=vinod.koul@intel.com \
    --cc=jic23@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.