From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Piel Subject: Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc) Date: Thu, 24 Jul 2008 14:37:23 +0200 Message-ID: <48887783.5000002@tremplin-utc.net> References: <488763AD.4050400@gmail.com> <20080723174801.GC11009@khazad-dum.debian.net> <48884F04.4070403@tremplin-utc.net> <48887201.8090300@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan Cameron , mgross@linux.intel.com, Dmitry Torokhov , LKML , LM Sensors , David Brownell , Henrique de Moraes Holschuh , Jean Delvare , spi-devel-general@lists.sourceforge.net, Ben Nizette To: Jonathan Cameron Return-path: In-Reply-To: <48887201.8090300@cam.ac.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Piel Date: Thu, 24 Jul 2008 12:37:23 +0000 Subject: Re: [lm-sensors] [spi-devel-general] [Patch 0/4] IndustrialIO Message-Id: <48887783.5000002@tremplin-utc.net> List-Id: References: <488763AD.4050400@gmail.com> <20080723174801.GC11009@khazad-dum.debian.net> <48884F04.4070403@tremplin-utc.net> <48887201.8090300@cam.ac.uk> In-Reply-To: <48887201.8090300@cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jonathan Cameron Cc: Jonathan Cameron , mgross@linux.intel.com, Dmitry Torokhov , LKML , LM Sensors , David Brownell , Henrique de Moraes Holschuh , Jean Delvare , spi-devel-general@lists.sourceforge.net, Ben Nizette 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 _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors