public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Jonathan Cameron <Jonathan.Cameron@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	spi-devel-general@lists.sourceforge.net,
	LM Sensors <lm-sensors@lm-sensors.org>,
	Dmitry Torokhov <dtor@mail.ru>
Subject: Re: Accelerometer, Gyros and ADC's etc within the kernel.
Date: Tue, 20 May 2008 13:28:17 +0200	[thread overview]
Message-ID: <20080520132817.03fb74ea@hyperion.delvare> (raw)
In-Reply-To: <4832A211.4040206@gmail.com>

Hi Jonathan,

On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> This email is basically a request for opinions on how and where such sensors
> should be integrated into the kernel.
> 
> To set the scene...
> 
> Increasing numbers of embedded devices are being supplied attached MEMS
> devices (www.xbow.com imote2 etc). Along with more traditional sensors such
> as ADC's not being used for hardware monitoring, these do not really 
> seem to
> fit with in an particular subsystem of the kernel.  A previous 
> discussion on
> lkml in 2006 considered the accelerometers to be found within some laptop
> hard drives, but I haven't been able to track down any more general 
> discussions
> of such non hardware monitoring sensors.
> 
> The obvious possibilities are:
> 
> * To place the various drivers within the spi / i2c etc subsystems as 
> relevant.

Bad idea. Grouping drivers by connectivity is almost always the wrong
thing to do, as it means that different persons will maintain them and
they have all chances to diverge. You really want to group drivers by
functionality. On top of that, I am busy enough maintaining the i2c
core and bus drivers without having more i2c device drivers added to my
plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

> * To place within the hwmon subsystem as this is probably closest.
> (there is already at least one straight ADC driver in hwmon)

Probably not the wisest choice, if nothing else, because the hwmon
maintainer is already overloaded. And I don't think that these devices
have much in common with the traditional hardware monitoring components
anyway.

I'm not sure what "straight ADC driver" you are referring to, but
anything which measures a voltage and exports the reading to user-space
is, well, a voltage sensor, and thus fix within hwmon. If the same chip
is used for a higher-level, dedicated function then we would probably
have a separate driver for it, outside of hwmon.

> * To create a new subsystem, or perhaps merely sysfs class to contain these
>   elements.

Would be OK. Or:

* Place these within the input subsystem. You might want to discuss
this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The
Wii remote is essentially a joystick, and joysticks belong to the input
subsystem.

> Typical requirements within an application include simply polling for 
> current
> readings, and using device triggered interrupts to grab data 
> continuously to a
> ring buffer, for collection by suitable userspace code.  Obviously it 
> would be
> desirable to standardize sysfs controls for various calibration 
> parameters as
> much as possible across the various devices.
> 
> Any other suggestions welcome!

This all sounds quite different from our hwmon drivers. Our hwmon
drivers read all the sensor values at once and cache the readings for a
couple seconds, so you can't get an instant reading at any time, and
they also don't support interrupts in general.

-- 
Jean Delvare

  reply	other threads:[~2008-05-20 11:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 10:04 Accelerometer, Gyros and ADC's etc within the kernel Jonathan Cameron
2008-05-20 11:28 ` Jean Delvare [this message]
2008-05-20 21:40   ` Hans J. Koch
2008-05-21 10:04     ` Jonathan Cameron
2008-05-21 13:20       ` Jean Delvare
2008-05-21 13:49   ` Dmitry Torokhov
2008-05-21 14:09     ` Henrique de Moraes Holschuh
2008-05-27 17:16     ` [spi-devel-general] " Ben Dooks
2008-05-27 19:01       ` Dmitry Torokhov
2008-05-22  0:52   ` David Brownell
2008-05-22  9:35     ` [spi-devel-general] " Jonathan Cameron
2008-05-26 16:23       ` Jonathan Cameron
2008-06-26 18:01   ` Accelerometer etc subsystem (Update on progress) Jonathan Cameron
2008-06-26 18:26     ` Jonathan Cameron
2008-06-27  2:39     ` Randy Dunlap
2008-06-27  3:29     ` Ben Nizette
2008-06-27  9:45       ` [lm-sensors] " Jonathan Cameron
2008-06-28  8:34         ` Ben Nizette
2008-06-28 15:34           ` Jonathan Cameron
2008-05-20 17:50 ` Accelerometer, Gyros and ADC's etc within the kernel mark gross
2008-05-21  9:40   ` [spi-devel-general] " Jonathan Cameron
2008-05-27 15:43     ` mark gross
2008-05-29 11:57       ` Jonathan Cameron
2008-05-22  0:53   ` David Brownell
2008-05-27 15:56     ` mark gross
2008-05-27 23:42       ` David Brownell
2008-05-27 16:44 ` [spi-devel-general] " Anton Vorontsov
2008-05-27 16:50   ` Ben Dooks
2008-05-27 17:01     ` Anton Vorontsov
2008-05-27 18:00     ` Jonathan Cameron
2008-05-27 18:12       ` Ben Dooks
2008-05-27 17:59   ` 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=20080520132817.03fb74ea@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=Jonathan.Cameron@gmail.com \
    --cc=dtor@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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