[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48FB6193.8090803@gmail.com>
Date: Sun, 19 Oct 2008 17:34:27 +0100
From: Jonathan Cameron <Jonathan.Cameron@...il.com>
To: Eric Piel <eric.piel@...mplin-utc.net>
CC: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Pavel Machek <pavel@...e.cz>,
Yan Burman <burman.yan@...il.com>,
Pau Oliva Fora <pau@...ack.org>
Subject: Re: [PATCH] LIS3LV02Dx Accelerometer driver (take 4)
Hi Eric,
Nice looking driver.
> * Several people suggested to not put it in hwmon but in the future industrialio susbsystem: fine with that but as the industrialio subsystem is not available yet, it's still in hwmon with the other accelerometer drivers for now, and I'll happily move it whenever industrialio is integrated.
>
Hmm.. might be a little while yet and there's still the debate on whether
support for input subsystem is a good idea (different requirements etc).
I'd be inclined to have a driver for this accelerometer in there, but the
form it may be somewhat different (for example, that datardy signal
is vital in the sort of apps iio is designed for!)
Also, looking at the code, I'm not sure how similar things are to the
equivalent i2c or spi interfaces. Guess that'll only become entirely
clear on implementation.
I'll try and get an updated version of industrialio patches as is out later
this week.
> +Sysfs attributes under /sys/devices/platform/lis3lv02d/:
> +position - 3D position that the accelerometer reports. Format: "(x,y,z)"
>
Hmm. Position? I've probably missed the debate on why it is called
this....
> +calibrate - read: values (x, y, z) that are used as the base for input class device operation.
> + write: forces the base to be recalibrated with the current position.
> +rate - reports the sampling rate of the accelerometer device in HZ
>
>
> +/*
> + * The sensor can also generate interrupts (DRDY) but it's pretty pointless
> + * because their are generated even if the data do not change.
Unless there is some serious filtering the noise level on such a chip
will mean
it almost always changes anyway. However, for this type of app I can
see your
point!
> So it's better
> + * to keep the interrupt for the free-fall event. The values are updated at
> + * 40Hz (at the lowest frequency), but as it can be pretty time consuming on
> + * some low processor, we poll the sensor only at 20Hz... enough for the
> + * joystick.
> + */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists