public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <eric.piel@tremplin-utc.net>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Jonathan Cameron <Jonathan.Cameron@gmail.com>,
	mgross@linux.intel.com, Dmitry Torokhov <dtor@mail.ru>,
	LKML <linux-kernel@vger.kernel.org>,
	LM Sensors <lm-sensors@lm-sensors.org>,
	David Brownell <david-b@pacbell.net>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Jean Delvare <khali@linux-fr.org>,
	spi-devel-general@lists.sourceforge.net,
	Ben Nizette <bn@niasdigital.com>
Subject: Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)
Date: Thu, 24 Jul 2008 14:37:23 +0200	[thread overview]
Message-ID: <48887783.5000002@tremplin-utc.net> (raw)
In-Reply-To: <48887201.8090300@cam.ac.uk>

Jonathan Cameron schreef:
:
>> * If the accelerometer is soldered on the computer, define once for all 
>> to which _physical_ movement corresponds which axis (eg: a laptop on its 
>> normal position going up has axis Z increasing).
> Agreed, though this is more documentation (and strict enforcement on drivers)
Indeed, it's more about defining conventions. A one page document saying 
to userspace developers how they can expect any accelerometer driver 
will behave is desperately needed. The more conventions, the more all 
the drivers will behave similarly, and the easier it will be for 
userspace programs to be written :-)

>> * Free fall event. Either it's hardware detected, or the accelerometer 
>> infrastructure will detect it in software.
> Hadn't thought of doing that in software - should be relatively straight
> forward, though would involve a fairly large overhead if the intention
> is to detect it fast enough to park hardware etc. (similar to that for
> the ring buffer I guess).  I'll look into getting that done for the next
> version (maybe driver specific for now).
Yes, on a second though, this is a low priority point. If userspace is 
able to know if the hardware has or not freefall detection, it should be 
possible to just implement the software detection in the userspace 
daemon. People might come up with lots of "clever" algorithms for that, 
so it might be better to not do too much in the kernel ;-)


> 
> At the moment the big missing element of the subsystem is an easy way of
> querying what is there. (proc interface similar to that for the input subsystem)
You mean /sys/class/input/, right? Indeed, something inspired by the 
input subsystem should work well.

See you,
Eric

  reply	other threads:[~2008-07-24 12:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 17:00 [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc) Jonathan Cameron
2008-07-23 17:08 ` [Patch 1/4] Industrialio Core Jonathan Cameron
2008-07-23 18:31   ` Anton Vorontsov
2008-07-24 10:12     ` [spi-devel-general] " Jonathan Cameron
2008-07-23 19:42   ` Ben Dooks
2008-07-24 10:33     ` Jonathan Cameron
2008-07-24  9:01   ` Eric Piel
2008-07-24 11:56     ` [spi-devel-general] " Jonathan Cameron
2008-07-23 17:11 ` [Patch 2/4] Max1363 (and similar) ADCs Jonathan Cameron
2008-07-23 17:14 ` [Patch 3/4] ST LIS3L02DQ accelerometer Jonathan Cameron
2008-07-23 17:07   ` Alan Cox
2008-07-23 17:44     ` Jonathan Cameron
2008-07-23 17:17 ` [Patch 4/4] VTI SCA3000 Series accelerometer driver Jonathan Cameron
2008-07-23 17:48 ` [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc) Henrique de Moraes Holschuh
2008-07-24  9:44   ` Eric Piel
2008-07-24 10:08     ` Ben Dooks
2008-07-24 12:20       ` [spi-devel-general] " Jonathan Cameron
2008-07-24 12:13     ` Jonathan Cameron
2008-07-24 12:37       ` Eric Piel [this message]
2008-07-24 12:45         ` Jonathan Cameron
2008-07-24 13:26           ` Dmitry Torokhov
2008-07-24 13:39             ` Jonathan Cameron
2008-07-23 18:36 ` David Brownell
2008-07-23 19:19 ` [spi-devel-general] " Ben Dooks
2008-07-24  7:41   ` Hans J. Koch
2008-07-24  9:19     ` Alan Cox
2008-07-24 12:28       ` Jonathan Cameron
2008-07-24 10:01     ` Ben Dooks
2008-07-24 15:38       ` Hans J. Koch
2008-07-24 16:11         ` Jonathan Cameron
2008-07-24 12:32   ` Jonathan Cameron
2008-07-23 19:33 ` Ben Dooks
2008-07-24 17:57 ` [Patch 5/4] IndustrialIO subsystem very early cut of documentation + userspace demo Jonathan Cameron
2008-07-24 22:25 ` [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc) Jan Engelhardt
2008-07-25 11:12   ` Jonathan Cameron
2008-07-25 11:28     ` Anton Vorontsov

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=48887783.5000002@tremplin-utc.net \
    --to=eric.piel@tremplin-utc.net \
    --cc=Jonathan.Cameron@gmail.com \
    --cc=bn@niasdigital.com \
    --cc=david-b@pacbell.net \
    --cc=dtor@mail.ru \
    --cc=hmh@hmh.eng.br \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mgross@linux.intel.com \
    --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