Re: [RFC PATCH 1/3] hwmon:driver support for Kionix kxte9 accelerometer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Jonathan Cameron wrote:
Chris Hudson wrote:
Jean Delvare wrote:
On Tue, 10 Nov 2009 13:28:47 -0500, chudson@xxxxxxxxxx wrote:
From: Chris Hudson <chudson@xxxxxxxxxx>

This is a request for comments for adding driver support for the
Kionix KXTE9 digital tri-axis accelerometer.  This part features
built-in tilt position (orientation), wake-up and back-to-sleep
algorithms, which can trigger a user-configurable physical
interrupt.  The driver uses i2c for device communication, a misc node
for IOCTLs, and input nodes for reporting acceleration data and
interrupt status information.

Signed-off-by: Chris Hudson <chudson@xxxxxxxxxx>
Nack. We want less accelerometer drivers polluting drivers/hwmon, not
more.

Thank you Jean for your quick reply.  I have seen some accelerometer
drivers in drivers/staging/iio/accel; is this where they are all being
moved to?

Sorry Chris, meant to send my reply to the list as this question keeps
coming up.

That somewhat depends on the intended application.  The purpose of IIO
is to provide a more general sensors framework, handling reasonably high
capture speeds and things like triggering and ring buffers.  As things
currently stand it isn't the place for devices that are principally being
used for input or as wake up triggers. I'd be perfectly happy if there
was a driver in IIO for this chip, (we already have a basic kxsd9 driver)
but the support for much of what you describe in your summary would be
pretty much unconnected to that subsystem. Not necessarily a problem
though handling exactly what was getting the data at a given moment
might get fiddly.
Jonathan
--

Thank you for your insight Jonathan. The driver was originally written for the 2.6.29 omap-android kernel to facilitate integration of the kxte9 into customer projects. Unfortunately, it seems that things in the kernel have changed since then, but I'm not sure how much we can change without sacrificing compatibility with the Android sensor API. Is there a different place where this driver could go without requiring significant redesign?

_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux