[spi-devel-general] [Industrial I/O] [0/13] RFC: IIO v3 patchset
Dear All, Sorry this has been so long in coming, it has been a busy couple of months. Summary of what IIO is about: The Industrial I/O (name open to suggestions) subsystem is the result of discussions on LKML about suitable facilities in the kernel for the handling of Analog to Digital Converters (ADCs) and the huge classes of sensor that act in similar fashion (digital accelerometers etc). The intention is that this may also provide a home for DACs as a lot of chips have both functions. The sort of devices we are talking typically communicate over I2C or SPI buses though drivers for rs232 devices etc are definitely on the cards. Basically we are interested in devices where direct memory mapped access is not possible. My particular motivation was to produce an adaptable data capture platform and, seeing as that's what is paying the bills, it has been the initial focus of my efforts. The RFCs below include the question of what other facilities should be included as options in this system. For discussion of why these don't fit within existing subsystems see http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. The design is intended to allow a disparate set of drivers providing whatever subset of functionality people have uses for. Hence, the intention is that it is not necessary or even desirable to support as much as the example drivers provided here. The system is designed to allow everything from simple drivers providing sysfs based reading of individual channels to the level of complexity seen in the sca3000 accelerometer driver found in patch 11. To this end any final submission will include at least one example of a minimal driver. I'm still fairly new to kernel coding so have doubtlessly made many mistakes and non optimal decisions within this code. So, whilst this is intended primarily to feed a discussion of the overall framework, I would be grateful to receive any more specific comments on the code! Particularly welcome are any suggestions that will result in reductions in code length without loss of functionality as this is still rather larger than would be ideal! As ever, thanks to the numerous people who commented on the last version posted and those who have been testing the various intermediate versions (Marcelo Pias in particular.) Contents: [1/13] The Industrial I/O core: The core registration and event handling functionality of IIO. [2/13] The Industrial I/O core - ring buffer support: Adds ring buffer handling to the IIO core. [3/13] IIO: Software ring buffer implementation. An example software ring buffer module. [4/13] The Industrial I/O core - trigger support Adds trigger support to the IIO core. [5/13] IIO: Periodic real time clock based trigger. An example of IIO trigger supplying driver. [6/13] IIO: Proof of concept GPIO based IIO trigger A very simple GPIO based trigger suitable for external synchronization. [7/13] IIO: Maxim MAX1363 driver Driver for the the MAX1363 ADC chip (core functionality) [8/13] IIO: Maxim MAX1363 driver (ring buffer support) Add triggered software ring buffer support to the driver [9/13] IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (core) Driver for the ST LIS3L02DQ accelerometer (SPI only) [10/13] IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (ring) Add triggered software ring buffer support and a data ready based trigger to the device. [11/13] IIO: VTI SCA3000 3d accelerometer driver. Driver for the VTI SCA3000 range of accelerometers. [12/13] IIO: Documentation Whilst most documentation related to IIO is contained as kernel doc comments within the source code, a brief overview of what it does and discussions of elements of individual drivers are provided in Documentation/industrialio. [13/13] IIO: Example user space ring buffer access. Simple example program to illustrate how a user space application can interact with the ring buffer functionality of IIO (this includes event handling). The example used uses the datardy trigger of the lis3l02dq to drive the filling of a software ring buffer from the lis3l02dq device. Overview of changes: * Introduction of trigger drivers to allow more flexible sampling strategies and separate out the periodic RTC element (as only one example of a trigger driver.) New triggers provided as example / proofs of concept are GPIO based for external sync and data ready on the lis3l02dq (to act as example of a unified iio:trigger / iio:device driver) * Far more modular design: - The core now acts as a registration system providing sysfs class handling and registration of chrdevs.
[spi-devel-general] [Industrial I/O] [3/13] RFC: IIO Software ring buffer implementation
From: Jonathan Cameron [EMAIL PROTECTED]
IIO: Software ring buffer implementation.
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
Intended to act as an example of how a software ring buffer might
function rather than as a definitive solution. The particular
focus of this was an application that required relatively hight
sampling rates (couple of Ksamples) with low computational load
and few dropped samples.
To my mind this is the most flakey element of this patch set.
All suggestions on alternative approaches / simplifications
would be most welcome. My intention is to also provide a far
simple locked ring buffer (hence all accesses in bh of interrupt
handlers) to act as a very simple example for people coding up
there own but this is not yet in place.
drivers/industrialio/Kconfig |9
drivers/industrialio/Makefile|4
drivers/industrialio/ring_sw.c | 370 +++
include/linux/industrialio/ring_sw.h | 183 +
4 files changed, 565 insertions(+), 1 deletion(-)
diff --git a/drivers/industrialio/Kconfig b/drivers/industrialio/Kconfig
index d132ab6..73c5616 100644
--- a/drivers/industrialio/Kconfig
+++ b/drivers/industrialio/Kconfig
@@ -17,3 +17,12 @@ config IIO_RING_BUFFER
Provide support for various ring buffer based data
acquisition methods.
+config IIO_SW_RING
+ tristate Industrial I/O lock free software ring
+ depends on IIO_RING_BUFFER INDUSTRIALIO
+
+ ---help---
+ example software ring buffer implementation. The design aim
+ of this particular realization was to minize write locking
+ with the intention that some devices would be able to write
+ in interrupt context.
\ No newline at end of file
diff --git a/drivers/industrialio/Makefile b/drivers/industrialio/Makefile
index 1f47af3..0fda138 100644
--- a/drivers/industrialio/Makefile
+++ b/drivers/industrialio/Makefile
@@ -3,5 +3,7 @@
#
obj-$(CONFIG_INDUSTRIALIO) += industrialio.o
-industrialio-y := industrialio-core.o
+industrialio-y := industrialio-core.o
industrialio-$(CONFIG_IIO_RING_BUFFER) += industrialio-ring.o
+
+obj-$(CONFIG_IIO_SW_RING) += ring_sw.o
diff --git a/drivers/industrialio/ring_sw.c b/drivers/industrialio/ring_sw.c
new file mode 100644
index 000..347ace1
--- /dev/null
+++ b/drivers/industrialio/ring_sw.c
@@ -0,0 +1,370 @@
+/* The industrial I/O simple minimally locked ring buffer.
+ *
+ * Copyright (c) 2008 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/workqueue.h
+#include linux/industrialio/ring_sw.h
+
+static inline int __iio_init_sw_ring_buffer(struct iio_sw_ring_buffer *ring,
+ int bytes_per_datum, int length)
+{
+ __iio_init_ring_buffer(ring-buf, bytes_per_datum, length);
+ ring-use_lock = __SPIN_LOCK_UNLOCKED((ring)-use_lock);
+ ring-data = kmalloc(length*ring-buf.bpd, GFP_KERNEL);
+
+ return ring-data ? 0 : -ENOMEM;
+}
+
+static inline void __iio_free_sw_ring_buffer(struct iio_sw_ring_buffer *ring)
+{
+ kfree(ring-data);
+}
+
+void iio_mark_sw_rb_in_use(void *r)
+{
+ struct iio_sw_ring_buffer *ring = r;
+ spin_lock(ring-use_lock);
+ ring-use_count++;
+ spin_unlock(ring-use_lock);
+}
+EXPORT_SYMBOL(iio_mark_sw_rb_in_use);
+
+void iio_unmark_sw_rb_in_use(void *r)
+{
+ struct iio_sw_ring_buffer *ring = r;
+ spin_lock(ring-use_lock);
+ ring-use_count--;
+ spin_unlock(ring-use_lock);
+}
+EXPORT_SYMBOL(iio_unmark_sw_rb_in_use);
+
+
+/* Ring buffer related functionality */
+/* Store to ring is typically called in the bh of a data ready interrupt
handler
+ * in the device driver */
+/* Lock always held if their is a chance this may be called */
+int iio_store_to_sw_ring(struct iio_sw_ring_buffer *ring,
+unsigned char *data,
+s64 timestamp)
+{
+ bool init_read = true;
+ int ret;
+ int code;
+
+ /* initial store */
+ if (unlikely(ring-write_p == 0)) {
+ ring-write_p = ring-data;
+ /* doesn't actually matter if this is out of the set */
+ ring-half_p = ring-data - ring-buf.length*ring-buf.bpd/2;
+ init_read = false;
+ }
+ memcpy(ring-write_p, data, ring-buf.bpd);
+ barrier();
+ ring-last_written_p = ring-write_p;
+ barrier();
+ ring-write_p += ring-buf.bpd;
+ /* End of ring, back to the beginning */
+ if (ring-write_p == ring-data + ring-buf.length*ring-buf.bpd) {
+ ring-write_p = ring-data;
+ ring-buf.loopcount++;
+ }
+ if (ring-read_p == 0)
+ ring-read_p =
[spi-devel-general] [Industrial I/O] [2/13] RFC: IIO ring buffer support (core)
From: Jonathan Cameron [EMAIL PROTECTED]
The Industrial I/O core - ring buffer support
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
This patch adds ring buffer support to the industrial I/O subsystem
core. This functionality may be disabled when not desired.
The support is designed to be generic enough to allow multiple
software implementations. At the moment only one is available so
the functionality for run time or board conf based selection has
not yet been implemented.
The framework also allows for hardware ring buffers existing on the
actual chip. An example of this usage is the VTI sca3000 driver found
later in this patch set.
drivers/industrialio/Kconfig |7
drivers/industrialio/Makefile |1
drivers/industrialio/industrialio-ring.c | 491 ++
include/linux/industrialio/ring_generic.h | 123 +++
4 files changed, 622 insertions(+)
diff --git a/drivers/industrialio/Kconfig b/drivers/industrialio/Kconfig
index 433f777..d132ab6 100644
--- a/drivers/industrialio/Kconfig
+++ b/drivers/industrialio/Kconfig
@@ -10,3 +10,10 @@ menuconfig INDUSTRIALIO
number of different physical interfaces (i2c, spi etc). See
Documentation/industrialio for more information.
+config IIO_RING_BUFFER
+ bool Enable ring buffer support within iio
+ depends on INDUSTRIALIO
+ help
+ Provide support for various ring buffer based data
+ acquisition methods.
+
diff --git a/drivers/industrialio/Makefile b/drivers/industrialio/Makefile
index 1acd8fa..1f47af3 100644
--- a/drivers/industrialio/Makefile
+++ b/drivers/industrialio/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_INDUSTRIALIO) += industrialio.o
industrialio-y := industrialio-core.o
+industrialio-$(CONFIG_IIO_RING_BUFFER) += industrialio-ring.o
diff --git a/drivers/industrialio/industrialio-ring.c
b/drivers/industrialio/industrialio-ring.c
new file mode 100644
index 000..04a8cb1
--- /dev/null
+++ b/drivers/industrialio/industrialio-ring.c
@@ -0,0 +1,491 @@
+/* The industrial I/O core
+ *
+ * Copyright (c) 2008 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * Handling of ring allocation / resizing.
+ *
+ *
+ * Things to look at here.
+ * - Better memory allocation techniques?
+ * - Alternative access techniques?
+ */
+#include linux/kernel.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/fs.h
+#include linux/poll.h
+#include linux/module.h
+#include linux/industrialio/iio.h
+#include linux/industrialio/ring_generic.h
+
+/* Allow for 3 digit id */
+#define IIO_RING_AC_MINOR_N_LEN 22
+#define IIO_RING_AC_MINOR_N ring_buf%d_acc_minor
+#define IIO_RING_EV_MINOR_N_LEN 21
+#define IIO_RING_EV_MINOR_N ring_buf%d_ev_minor
+
+int iio_push_ring_event(struct iio_ring_buffer *ring_buf,
+ int event_code,
+ s64 timestamp)
+{
+ return __iio_push_event(ring_buf-ev_int,
+ event_code,
+ timestamp,
+ ring_buf-shared_ev_pointer);
+}
+EXPORT_SYMBOL(iio_push_ring_event);
+
+int iio_push_or_escallate_ring_event(struct iio_ring_buffer *ring_buf,
+ int event_code,
+ s64 timestamp)
+{
+ if (ring_buf-shared_ev_pointer.ev_p)
+ __iio_change_event(ring_buf-shared_ev_pointer.ev_p,
+ event_code,
+ timestamp);
+ else
+ return iio_push_ring_event(ring_buf,
+ event_code,
+ timestamp);
+ return 0;
+}
+EXPORT_SYMBOL(iio_push_or_escallate_ring_event);
+
+/**
+ * iio_ring_open() chrdev file open for ring buffer access
+ *
+ * This function relies on all ring buffer implementations having an
+ * iio_ring_buffer as their first element.
+ **/
+int iio_ring_open(struct inode *inode, struct file *filp)
+{
+ void *r = filp-private_data;
+ struct iio_ring_buffer *rb = r;
+
+ if (rb-ring_access-mark_in_use)
+ rb-ring_access-mark_in_use(r);
+ try_module_get(rb-access_minor_attr.dev_attr.attr.owner);
+
+ return 0;
+}
+
+/**
+ * iio_ring_release() chrdev file close ring buffer access
+ *
+ * This function relies on all ring buffer implementations having an
+ * iio_ring_buffer as their first element.
+ **/
+int iio_ring_release(struct inode *inode, struct file *filp)
+{
+ void *r = filp-private_data;
+ struct iio_ring_buffer *rb = r;
+
+ module_put(rb-access_minor_attr.dev_attr.attr.owner);
+ clear_bit(IIO_BUSY_BIT_POS, rb-access_handler.flags);
+ if (rb-ring_access-unmark_in_use)
+ rb-ring_access-unmark_in_use(r);
+
[spi-devel-general] [Industrial I/O] [5/13] RFC: IIO Periodic real time clock based trigger.
From: Jonathan Cameron [EMAIL PROTECTED]
IIO: Periodic real time clock based trigger.
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
Quite a few real time clock implementations provide configurable
periodic interrupts. This module allows these to be used as triggers
for filling IIO ring buffers at regular intervals.
As has been discussed a number of times on LKML and elsewhere, it
would be nice to have a generic timer system to handle the many
timers that are available and make use of their periodic capabilities.
Until this is available the RTC subsystem provides the easiest way
of doing this.
Whilst this is in of itself a useful implementation, the principal
reason for including it here is to illustrate how IIO trigger drivers
work.
drivers/industrialio/Kconfig |2 +
drivers/industrialio/Makefile |2 +
drivers/industrialio/triggers/Kconfig |6 +
drivers/industrialio/triggers/Makefile |5 +
.../industrialio/triggers/iio-trig-periodic-rtc.c | 197
include/linux/industrialio/prtc_trigger.h |7 +
6 files changed, 219 insertions(+), 0 deletions(-)
diff --git a/drivers/industrialio/Kconfig b/drivers/industrialio/Kconfig
index 9bf6a36..c20ca2f 100644
--- a/drivers/industrialio/Kconfig
+++ b/drivers/industrialio/Kconfig
@@ -19,6 +19,8 @@ config IIO_TRIGGERS
ring buffers. The triggers are effectively a 'capture
data now' interrupt.
+source drivers/industrialio/triggers/Kconfig
+
config IIO_RING_BUFFER
bool Enable ring buffer support within iio
depends on INDUSTRIALIO
diff --git a/drivers/industrialio/Makefile b/drivers/industrialio/Makefile
index 15ef75f..518849a 100644
--- a/drivers/industrialio/Makefile
+++ b/drivers/industrialio/Makefile
@@ -8,3 +8,5 @@ industrialio-$(CONFIG_IIO_RING_BUFFER) += industrialio-ring.o
industrialio-$(CONFIG_IIO_TRIGGERS) += industrialio-trigger.o
obj-$(CONFIG_IIO_SW_RING) += ring_sw.o
+
+obj-y += triggers/
\ No newline at end of file
diff --git a/drivers/industrialio/triggers/Kconfig
b/drivers/industrialio/triggers/Kconfig
new file mode 100644
index 000..20e6498
--- /dev/null
+++ b/drivers/industrialio/triggers/Kconfig
@@ -0,0 +1,6 @@
+config IIO_PERIODIC_RTC_TRIGGER
+ tristate Periodic RTC triggers
+ depends on INDUSTRIALIO IIO_TRIGGERS RTC_CLASS
+ help
+ Provides support for using periodic capable real time
+ clocks as IIO triggers.
diff --git a/drivers/industrialio/triggers/Makefile
b/drivers/industrialio/triggers/Makefile
new file mode 100644
index 000..4ae55b9
--- /dev/null
+++ b/drivers/industrialio/triggers/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for triggers not associated with iio-devices
+#
+obj-$(CONFIG_IIO_PERIODIC_RTC_TRIGGER) += iio-trig-periodic-rtc.o
+
diff --git a/drivers/industrialio/triggers/iio-trig-periodic-rtc.c
b/drivers/industrialio/triggers/iio-trig-periodic-rtc.c
new file mode 100644
index 000..c395722
--- /dev/null
+++ b/drivers/industrialio/triggers/iio-trig-periodic-rtc.c
@@ -0,0 +1,197 @@
+/* The industrial I/O periodic RTC trigger driver
+ *
+ * Copyright (c) 2008 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This is a heavily rewritten version of the periodic timer system in
+ * earlier version of industrialio. It supplies the same functionality
+ * but via a trigger rather than a specific periodic timer system.
+ */
+
+#include linux/platform_device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/rtc.h
+#include linux/industrialio/iio.h
+#include linux/industrialio/trigger.h
+#include linux/industrialio/prtc_trigger.h
+
+LIST_HEAD(iio_prtc_trigger_list);
+DEFINE_MUTEX(iio_prtc_trigger_list_lock);
+
+struct iio_prtc_trigger_info {
+ struct rtc_device *rtc;
+ int frequency;
+ struct rtc_task task;
+};
+
+static int iio_trig_periodic_rtc_set_state(struct iio_trigger *trig, bool
state)
+{
+ struct iio_prtc_trigger_info *trig_info = trig-private_data;
+ return rtc_irq_set_state(trig_info-rtc, trig_info-task, state);
+}
+
+static ssize_t iio_trig_periodic_read_freq(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_trigger *trig = dev_get_drvdata(dev);
+ struct iio_prtc_trigger_info *trig_info = trig-private_data;
+ return sprintf(buf, %u\n, trig_info-frequency);
+}
+
+static ssize_t iio_trig_periodic_write_freq(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
+{
+ struct iio_trigger *trig =
[spi-devel-general] [Industrial I/O] [6/13] RFC: Proof of concept GPIO based IIO trigger
From: Jonathan Cameron [EMAIL PROTECTED]
IIO: Proof of concept GPIO based IIO trigger
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
A very limited trigger driver using a GPIO to provide synchronization
with external devices. Things like setting polarity and interrupt
types will need to be added to make this more useful.
drivers/industrialio/triggers/Kconfig | 12 ++
drivers/industrialio/triggers/Makefile|5 +-
drivers/industrialio/triggers/iio-trig-gpio.c | 193 +
include/linux/industrialio/gpio_trigger.h |6 +
4 files changed, 215 insertions(+), 1 deletions(-)
diff --git a/drivers/industrialio/triggers/Kconfig
b/drivers/industrialio/triggers/Kconfig
index 20e6498..e100098 100644
--- a/drivers/industrialio/triggers/Kconfig
+++ b/drivers/industrialio/triggers/Kconfig
@@ -1,6 +1,18 @@
+config IIO_GPIO_TRIGGER
+ tristate GPIO triggers
+ depends on INDUSTRIALIO IIO_TRIGGERS GENERIC_GPIO
+ help
+ Driver provides support for using GPIOs as the IIO
+ triggers.
+
config IIO_PERIODIC_RTC_TRIGGER
tristate Periodic RTC triggers
depends on INDUSTRIALIO IIO_TRIGGERS RTC_CLASS
help
Provides support for using periodic capable real time
clocks as IIO triggers.
diff --git a/drivers/industrialio/triggers/Makefile
b/drivers/industrialio/triggers/Makefile
index 4ae55b9..767d2cd 100644
--- a/drivers/industrialio/triggers/Makefile
+++ b/drivers/industrialio/triggers/Makefile
@@ -1,5 +1,8 @@
#
# Makefile for triggers not associated with iio-devices
#
-obj-$(CONFIG_IIO_PERIODIC_RTC_TRIGGER) += iio-trig-periodic-rtc.o
+obj-$(CONFIG_IIO_GPIO_TRIGGER) += iio-trig-gpio.o
+
+obj-$(CONFIG_IIO_PERIODIC_RTC_TRIGGER) += iio-trig-periodic-rtc.o
+#obj-$(CONFIG_IIO_PTIMER_BOARDINFO) += iio-ptimer-boardinfo.o
diff --git a/drivers/industrialio/triggers/iio-trig-gpio.c
b/drivers/industrialio/triggers/iio-trig-gpio.c
new file mode 100644
index 000..9718779
--- /dev/null
+++ b/drivers/industrialio/triggers/iio-trig-gpio.c
@@ -0,0 +1,193 @@
+/*
+ * Industrial I/O - gpio based trigger support
+ *
+ * Copyright (c) 2008 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * Currently this is more of a functioning proof of concept that a fully
+ * fledged trigger driver.
+ *
+ * TODO:
+ *
+ * Add board config elements to allow specification of startup settings.
+ * Add configuration settings (irq type etc)
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/gpio.h
+
+#include linux/industrialio/iio.h
+#include linux/industrialio/trigger.h
+#include linux/industrialio/gpio_trigger.h
+
+LIST_HEAD(iio_gpio_trigger_list);
+DEFINE_MUTEX(iio_gpio_trigger_list_lock);
+
+struct iio_gpio_trigger_info {
+ struct mutex in_use;
+ int gpio;
+};
+/* Need to reference count these triggers and only enable gpio interrupts as
appropriate.*/
+
+/* So what functionality do we want in here?... */
+/* set high / low as interrupt type? */
+
+static irqreturn_t iio_gpio_trigger_poll(int irq, void *private)
+{
+ //private at this stage is the iio_trig.
+ iio_trigger_poll(private);
+ return IRQ_HANDLED;
+}
+
+DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
+
+static struct attribute *iio_gpio_trigger_attrs[] = {
+ dev_attr_name.attr,
+ NULL,
+};
+
+static const struct attribute_group iio_gpio_trigger_attr_group = {
+ .attrs = iio_gpio_trigger_attrs,
+};
+
+static int iio_gpio_trigger_probe(struct platform_device *dev)
+{
+ struct iio_gpio_trigger_pdata *pdata = dev-dev.platform_data;
+ struct iio_gpio_trigger_info *trig_info;
+ struct iio_trigger *trig, *trig2;
+ int i, irq, ret = 0;
+ if (!pdata) {
+ printk(KERN_ERR No IIO gpio trigger platform data found\n);
+ return -EINVAL;
+ }
+ for (i = 0; i pdata-num_gpios; i++) {
+
+ trig = kzalloc(sizeof(*trig), GFP_KERNEL);
+ if (!trig) {
+ ret = -ENOMEM;
+ goto error_free_trigs_1;
+ }
+ iio_trigger_init(trig);
+
+ trig_info = kzalloc(sizeof(*trig_info), GFP_KERNEL);
+ if (!trig_info) {
+ ret = -ENOMEM;
+ goto error_free_trigs_2;
+ }
+ trig-control_attrs = iio_gpio_trigger_attr_group;
+ trig-private_data = trig_info;
+ trig_info-gpio = pdata-gpios[i];
+ trig-owner = THIS_MODULE;
+ trig-name = kmalloc(IIO_TRIGGER_NAME_LENGTH, GFP_KERNEL);
+ snprintf((char *)trig-name, IIO_TRIGGER_NAME_LENGTH,
gpiotrig%d,
[spi-devel-general] [Industrial I/O] [7/13] RFC: Maxim MAX1363 driver
From: Jonathan Cameron [EMAIL PROTECTED] IIO: Maxim MAX1363 driver Also supports max1361, max1362, max1364, max1136, max1136, max1137, max1138, max1139, max1236, max1237, max11238, max1239 Signed-off-by: Jonathan Cameron [EMAIL PROTECTED] -- This patch provides the core functionality (sysfs control and direct device scanning, chrdev event interface). It illustrates one common form of scan mode configuration found in numerous similar devices. A restricted set of combinations of elements are possible via a set of predefined scan modes. How to handle this in a consistent way alongside devices such as the lis3l02dq accelerometer (any combinations of channels possible) is very much a question for discussion. drivers/industrialio/Kconfig|4 +- drivers/industrialio/Makefile |3 +- drivers/industrialio/adc/Kconfig| 13 + drivers/industrialio/adc/Makefile |7 + drivers/industrialio/adc/max1363.h | 250 + drivers/industrialio/adc/max1363_core.c | 599 +++ 6 files changed, 874 insertions(+), 2 deletions(-) diff --git a/drivers/industrialio/Kconfig b/drivers/industrialio/Kconfig index c20ca2f..f682fbf 100644 --- a/drivers/industrialio/Kconfig +++ b/drivers/industrialio/Kconfig @@ -36,4 +36,6 @@ config IIO_SW_RING example software ring buffer implementation. The design aim of this particular realization was to minize write locking with the intention that some devices would be able to write - in interrupt context. \ No newline at end of file + in interrupt context. + +source drivers/industrialio/adc/Kconfig \ No newline at end of file diff --git a/drivers/industrialio/Makefile b/drivers/industrialio/Makefile index 518849a..dd6d5ca 100644 --- a/drivers/industrialio/Makefile +++ b/drivers/industrialio/Makefile @@ -9,4 +9,5 @@ industrialio-$(CONFIG_IIO_TRIGGERS) += industrialio-trigger.o obj-$(CONFIG_IIO_SW_RING) += ring_sw.o -obj-y += triggers/ \ No newline at end of file +obj-y += triggers/ +obj-y += adc/ \ No newline at end of file diff --git a/drivers/industrialio/adc/Kconfig b/drivers/industrialio/adc/Kconfig new file mode 100644 index 000..203a5f9 --- /dev/null +++ b/drivers/industrialio/adc/Kconfig @@ -0,0 +1,13 @@ +# +# ADC drivers +# +comment Analog to digital convertors + depends on INDUSTRIALIO +config MAX1363 + tristate MAXIM max1363 ADC driver + depends on INDUSTRIALIO + help + Say yes here to build support for many MAXIM i2c analog to digital + convertors (ADC). (max1361, max1362, max1363, max1364, max1136, + max1136, max1137, max1138, max1139, max1236, max1237, max11238, + max1239) Provides direct access via sysfs. diff --git a/drivers/industrialio/adc/Makefile b/drivers/industrialio/adc/Makefile new file mode 100644 index 000..2a37fee --- /dev/null +++ b/drivers/industrialio/adc/Makefile @@ -0,0 +1,7 @@ + +# Makefile for industrial I/O ADC drivers +# + +max1363-y := max1363_core.o + +obj-$(CONFIG_MAX1363) += max1363.o diff --git a/drivers/industrialio/adc/max1363.h b/drivers/industrialio/adc/max1363.h new file mode 100644 index 000..71e9577 --- /dev/null +++ b/drivers/industrialio/adc/max1363.h @@ -0,0 +1,250 @@ +#ifndef _MAX1363_H_ +#define _MAX1363_H_ + +#define MAX1363_SETUP_BYTE(a) ((a) | 0x80) + +/* There is a fair bit more defined here than currently + * used, but the intention is to support everything these + * chips do in the long run */ + +/* see data sheets */ +/* max1363 and max1236, max1237, max1238, max1239 */ +#define MAX1363_SETUP_AIN3_IS_AIN3_REF_IS_VDD 0x00 +#define MAX1363_SETUP_AIN3_IS_REF_EXT_TO_REF 0x20 +#define MAX1363_SETUP_AIN3_IS_AIN3_REF_IS_INT 0x40 +#define MAX1363_SETUP_AIN3_IS_REF_REF_IS_INT 0x60 +#define MAX1363_SETUP_POWER_UP_INT_REF 0x10 +#define MAX1363_SETUP_POWER_DOWN_INT_REF 0x00 + + +#define MAX1363_SETUP_EXT_CLOCK0x08 +#define MAX1363_SETUP_INT_CLOCK0x00 +#define MAX1363_SETUP_UNIPOLAR 0x00 +#define MAX1363_SETUP_BIPOLAR 0x04 +#define MAX1363_SETUP_RESET0x00 +#define MAX1363_SETUP_NORESET 0x02 +/* max1363 only - though don't care on others. + * For now monitor modes are not implemented as the relevant + * line is not connected on my test board. + * The definitions are here as I intend to add this soon. + */ +#define MAX1363_SETUP_MONITOR_SETUP0x01 + +/* Specific to the max1363 */ +#define MAX1363_MON_RESET_CHAN(a) (1 ((a) + 4)) +#define MAX1363_MON_CONV_RATE_133ksps 0 +#define MAX1363_MON_CONV_RATE_66_5ksps 0x02 +#define MAX1363_MON_CONV_RATE_33_3ksps 0x04 +#define MAX1363_MON_CONV_RATE_16_6ksps 0x06 +#define MAX1363_MON_CONV_RATE_8_3ksps 0x08 +#define MAX1363_MON_CONV_RATE_4_2ksps 0x0A +#define MAX1363_MON_CONV_RATE_2_0ksps 0x0C +#define
[spi-devel-general] [Industrial I/O] [9/13] RFC: ST LIS3L02DQ 3d accelerometer driver via SPI (core)
From: Jonathan Cameron [EMAIL PROTECTED] IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (core) Signed-off-by: Jonathan Cameron [EMAIL PROTECTED] -- This is a fairly typical SPI accelerometer. I2C functionality will be added at a later date. Features: Variable sampling rates Data ready signal to indicate new data -this is awkward as it will go high on any channel having new data and hence needs complex handler. Axis by axis gain and offset adjustment. Axis threshold detector (single theshold for all 3) drivers/industrialio/Kconfig |1 + drivers/industrialio/Makefile |3 +- drivers/industrialio/accelerometer/Kconfig | 21 + drivers/industrialio/accelerometer/Makefile|6 + drivers/industrialio/accelerometer/lis3l02dq.h | 218 + .../industrialio/accelerometer/lis3l02dq_core.c| 886 include/linux/industrialio/accel.h | 157 7 files changed, 1291 insertions(+), 1 deletions(-) diff --git a/drivers/industrialio/Kconfig b/drivers/industrialio/Kconfig index f682fbf..58bfbd7 100644 --- a/drivers/industrialio/Kconfig +++ b/drivers/industrialio/Kconfig @@ -38,4 +38,5 @@ config IIO_SW_RING with the intention that some devices would be able to write in interrupt context. +source drivers/industrialio/accelerometer/Kconfig source drivers/industrialio/adc/Kconfig \ No newline at end of file diff --git a/drivers/industrialio/Makefile b/drivers/industrialio/Makefile index dd6d5ca..453dcc3 100644 --- a/drivers/industrialio/Makefile +++ b/drivers/industrialio/Makefile @@ -10,4 +10,5 @@ industrialio-$(CONFIG_IIO_TRIGGERS) += industrialio-trigger.o obj-$(CONFIG_IIO_SW_RING) += ring_sw.o obj-y += triggers/ -obj-y += adc/ \ No newline at end of file +obj-y += adc/ +obj-y += accelerometer/ \ No newline at end of file diff --git a/drivers/industrialio/accelerometer/Kconfig b/drivers/industrialio/accelerometer/Kconfig new file mode 100644 index 000..7e011a6 --- /dev/null +++ b/drivers/industrialio/accelerometer/Kconfig @@ -0,0 +1,21 @@ +# +# Accelerometer drivers +# +comment Accelerometers + depends on INDUSTRIALIO +config LIS3L02DQ + tristate ST Microelectronics LIS3L02DQ Accelerometer Driver + depends on INDUSTRIALIO + help + Say yes here to build generic support for the ST microelectronics + accelerometer. You will also need to one or more of the bus specific + elements below. The driver supplies direct access via sysfs files + and a software ring buffer using a supplied datardy interrupt. + +config LIS3L02DQ_SPI + depends on LIS3L02DQ SPI + tristate SPI support + help + Say yes here to build support for the ST LIS3L02DQ accelerometer via + an SPI bus. + diff --git a/drivers/industrialio/accelerometer/Makefile b/drivers/industrialio/accelerometer/Makefile new file mode 100644 index 000..22f3d87 --- /dev/null +++ b/drivers/industrialio/accelerometer/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for industrial I/O accelerometer drivers +# + +lis3l02dq-y := lis3l02dq_core.o +obj-$(CONFIG_LIS3L02DQ_SPI):= lis3l02dq.o diff --git a/drivers/industrialio/accelerometer/lis3l02dq.h b/drivers/industrialio/accelerometer/lis3l02dq.h new file mode 100644 index 000..f53b68b --- /dev/null +++ b/drivers/industrialio/accelerometer/lis3l02dq.h @@ -0,0 +1,218 @@ +/* + * LISL02DQ.h -- support STMicroelectronics LISD02DQ + * 3d 2g Linear Accelerometers via SPI + * + * Copyright (c) 2007 Jonathan Cameron [EMAIL PROTECTED] + * + * Loosely based upon tle62x0.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef SPI_LIS3L02DQ_H_ +#define SPI_LIS3L02DQ_H_ +#define LIS3L02DQ_READ_REG(a) ((a) | 0x80) +#define LIS3L02DQ_WRITE_REG(a) a + +/* Calibration parameters */ +#define LIS3L02DQ_REG_OFFSET_X_ADDR0x16 +#define LIS3L02DQ_REG_OFFSET_Y_ADDR0x17 +#define LIS3L02DQ_REG_OFFSET_Z_ADDR0x18 + +#define LIS3L02DQ_REG_GAIN_X_ADDR 0x19 +#define LIS3L02DQ_REG_GAIN_Y_ADDR 0x1A +#define LIS3L02DQ_REG_GAIN_Z_ADDR 0x1B + +/* Control Register (1 of 2) */ +#define LIS3L02DQ_REG_CTRL_1_ADDR 0x20 +/* Power ctrl - either bit set corresponds to on*/ +#define LIS3L02DQ_REG_CTRL_1_PD_ON 0xC0 + +/* Decimation Factor */ +#define LIS3L02DQ_DEC_MASK 0x30 +#define LIS3L02DQ_REG_CTRL_1_DF_1280x00 +#define LIS3L02DQ_REG_CTRL_1_DF_64 0x10 +#define LIS3L02DQ_REG_CTRL_1_DF_32 0x20 +#define LIS3L02DQ_REG_CTRL_1_DF_8 (0x10 | 0x20) + +/* Self Test Enable */ +#define LIS3L02DQ_REG_CTRL_1_SELF_TEST_ON 0x08 + +/* Axes enable ctrls */ +#define
[spi-devel-general] [Industrial I/O] [10/13] RFC: ST LIS3L02DQ 3d accelerometer driver via SPI (ring)
From: Jonathan Cameron [EMAIL PROTECTED]
IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (ring)
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
This patch adds triggered software ring buffer support to the
lis3l02dq driver. It also adds a new trigger from the data
ready signal of the lis3l02dq. The presence of a data ready
signal is common for these sorts of devices and as one will
often want to trigger other sensors at the same frequency
within multimodal sensing systems, it is useful to have this
as an IIO trigger.
drivers/industrialio/accelerometer/Makefile|4 +-
drivers/industrialio/accelerometer/lis3l02dq.h | 20 +-
.../industrialio/accelerometer/lis3l02dq_ring.c| 600
3 files changed, 622 insertions(+), 2 deletions(-)
diff --git a/drivers/industrialio/accelerometer/Makefile
b/drivers/industrialio/accelerometer/Makefile
index 22f3d87..3079723 100644
--- a/drivers/industrialio/accelerometer/Makefile
+++ b/drivers/industrialio/accelerometer/Makefile
@@ -3,4 +3,6 @@
#
lis3l02dq-y := lis3l02dq_core.o
-obj-$(CONFIG_LIS3L02DQ_SPI):= lis3l02dq.o
+#RFC separate config param per device?
+lis3l02dq-$(CONFIG_IIO_RING_BUFFER) += lis3l02dq_ring.o
+obj-$(CONFIG_LIS3L02DQ_SPI):= lis3l02dq.o
\ No newline at end of file
diff --git a/drivers/industrialio/accelerometer/lis3l02dq.h
b/drivers/industrialio/accelerometer/lis3l02dq.h
index f53b68b..5ff9bc3 100644
--- a/drivers/industrialio/accelerometer/lis3l02dq.h
+++ b/drivers/industrialio/accelerometer/lis3l02dq.h
@@ -183,6 +183,24 @@ int lis3l02dq_spi_write_reg_8(struct device *dev,
#define LIS3L02DQ_SCAN_ACC_Y 1
#define LIS3L02DQ_SCAN_ACC_Z 2
/* temporary disable */
+#ifdef CONFIG_IIO_RING_BUFFER
+/* At the moment triggers are only used for ring buffer
+ * filling. This may change!
+ */
+void lis3l02dq_remove_trigger(struct iio_dev *indio_dev);
+int lis3l02dq_probe_trigger(struct iio_dev *indio_dev);
+
+ssize_t lis3l02dq_read_accel_from_ring(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+
+
+int lis3l02dq_register_ring_funcs(struct iio_dev *indio_dev);
+void lis3l02dq_unregister_ring_funcs(struct iio_dev *indio_dev);
+
+int lis3l02dq_set_ring_length(struct iio_dev *indio_dev, int length);
+#else
static inline void lis3l02dq_remove_trigger(struct iio_dev *indio_dev){};
static inline int lis3l02dq_probe_trigger(struct iio_dev *indio_dev)
@@ -210,7 +228,7 @@ int lis3l02dq_set_ring_length(struct iio_dev *indio_dev,
int length)
return 0;
};
-
+#endif
#endif /* SPI_LIS3L02DQ_H_ */
diff --git a/drivers/industrialio/accelerometer/lis3l02dq_ring.c
b/drivers/industrialio/accelerometer/lis3l02dq_ring.c
new file mode 100644
index 000..f9b2b50
--- /dev/null
+++ b/drivers/industrialio/accelerometer/lis3l02dq_ring.c
@@ -0,0 +1,600 @@
+
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/gpio.h
+#include linux/workqueue.h
+#include linux/mutex.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/spi/spi.h
+#include linux/sysfs.h
+#include linux/list.h
+
+#include linux/industrialio/iio.h
+#include linux/industrialio/sysfs.h
+#include linux/industrialio/ring_sw.h
+#include linux/industrialio/accel.h
+#include linux/industrialio/trigger.h
+#include lis3l02dq.h
+
+/**
+ * count_to_right() counts number of set bits to right
+ * @full: variable in which bits are counted
+ * @mask: the bit mask (single bit set)
+ **/
+static inline u8 count_to_right(u16 full, u16 mask)
+{
+ u8 count = 0;
+ while (mask) {
+ mask = 1;
+ if (mask full)
+ count++;
+ }
+ return count;
+}
+
+/**
+ * combine_8_to_16() utility function to munge to u8s into u16
+ **/
+static inline u16 combine_8_to_16(u8 lower, u8 upper)
+{
+ u16 _lower = lower;
+ u16 _upper = upper;
+ return _lower | (_upper 8);
+}
+
+/**
+ * lis3l02dq_scan_el_set_state() set whether a scan contains a given channel
+ * @scan_el: associtate iio scan element attribute
+ * @indio_dev: the device structure
+ * @bool: desired state
+ *
+ * mlock already held when this is called.
+ **/
+static int lis3l02dq_scan_el_set_state(struct iio_scan_el *scan_el,
+ struct iio_dev *indio_dev,
+ bool state)
+{
+ u8 t, mask;
+ int ret;
+
+ ret = lis3l02dq_spi_read_reg_8(indio_dev-dev,
+ LIS3L02DQ_REG_CTRL_1_ADDR,
+ t);
+ if (ret)
+ goto error_ret;
+ switch (scan_el-label) {
+ case LIS3L02DQ_REG_OUT_X_L_ADDR:
+ mask = LIS3L02DQ_REG_CTRL_1_AXES_X_ENABLE;
+ break;
+ case LIS3L02DQ_REG_OUT_Y_L_ADDR:
+ mask = LIS3L02DQ_REG_CTRL_1_AXES_Y_ENABLE;
+ break;
+ case
[spi-devel-general] [Industrial I/O] [12/13] RFC: IIO Documentation
From: Jonathan Cameron [EMAIL PROTECTED] The Industrial I/O Documentation. Signed-off-by: Jonathan Cameron [EMAIL PROTECTED] -- This patch provides some documentation for the industrial I/O (IIO) subsystem. Much of the documentation is as kernel-doc comments within the code, but an overview is provided here along with some specific details of ring buffering and the max1363 driver. Documentation/industrialio/iio_ring.txt | 90 +++ Documentation/industrialio/max1363.txt | 37 + Documentation/industrialio/overview.txt | 76 ++ 3 files changed, 203 insertions(+), 0 deletions(-) diff --git a/Documentation/industrialio/iio_ring.txt b/Documentation/industrialio/iio_ring.txt new file mode 100644 index 000..410a552 --- /dev/null +++ b/Documentation/industrialio/iio_ring.txt @@ -0,0 +1,90 @@ +Industrialio subsystem ring buffers + +The industrial io subsystem supports both hardware (eg. sca3000) and software +(eg. max1363 and lis3l02dq) ring buffers. + +For both types a chrdev is used to provide events to userspace. These merely +contain an id and a timestamp. + +This is used to provide notifications of the ring having reached a certain level +(50%, 75%, 100%). + +Direct access to the contents of the ring buffer is available via a second +chrdev. The data output is pretty much raw device readings, so a userspace +function is needed to convert these into appropriate SI units. This function +should be provided in a device specific header if appropriate. + +The hardware ring buffer simply implements the above functionality by pulling +data directly from the device on demand (sca3000). + +The software ring buffer is somewhat more complex. + +The design considerations for this are: + +1) Writing should be as latency free as possible (preferably lock free) +2) As few samples as possible should be missed (ideally none - but as + we aren't dealing with a realtime OS some will occasionally be lost). +3) Reading does not lock the buffer but instead takes a copy then validate + what data is definitely good approach. +4) The filling of the buffer should be either driver by the device (datardy) + or if that is not possible via a periodic time source. +5) All latencies should be as small as possible (wishful thinking ;) + +The code in industrialio-ring.c meets most of these requirements and hopefuly +does not have any critical failure cases. + +A number of pointers into a static array are maintained. + +write_p - the next location to write to. +read_p - the oldest location from which we may read (start point for copying) +last_written_p - the newest location from which we may read (used to provide + direct access whilst the ring buffer is in use, without adding + to the communications with the sensor. + +half_p - Kept half the length of the buffer behind the write pointer and used + in conjunction with read_p to trigger an event when the buffer is half + full. + +The events are designed to escalate until we reach the point of buffer 100% +full. Thus a single event has it's code changed when it becomes outdated. + +The other interesting bit is reading data from the ring. Currently this is via +normal file reads rather than mmaping the ring buffer. + +1) A copy of the ring buffer between read_p and write_p is made. This is done +without locking the buffer in anyway so the data is not guaranteed to have not +been changed by subsequent writes. + +2) The value of read_p after the copy is used to provide a worst case location +for where we have clean data from. There is an obvious nasty case of the read +pointer having wrapped all the way round the buffer. For now we assume the +capture rate is slow enough that this will not have happened. + +Only the valid data is then sent to userspace. + +What the iio_dev ring parameters are + [EMAIL PROTECTED] Number of bytes per 'reading', this includes timestamp + [EMAIL PROTECTED] Number of readings in the ring + +The four functions are concerned with behaviour around the point where the +device mode actually switches. [EMAIL PROTECTED] - usually things like disabling unwanted (sensor side) + interrupts. + [EMAIL PROTECTED] - usually actually enabling the data ready generation if +appropriate. + [EMAIL PROTECTED] - usually disabling data ready generation [EMAIL PROTECTED] - restoring anything disable before the the ring came into + use. + [EMAIL PROTECTED] - For perioidic timer based rings, this function is called on + each timer interrupt. Reads from the device and pushes the + data into the ring. Also tends to grab a timestamp at the + point likely to be as close as possible to when the data + was acquired. Sensor specific offsets can compensate for + some fixed lags (particularly at low bus speeds). + +More information is available in
[spi-devel-general] [Industrial I/O] [13/13] RFC: Example user space application
From: Jonathan Cameron [EMAIL PROTECTED]
IIO: Example user space application. Configures and then reads
from a software ring buffer which is filled based on a the
lis3l02dq data ready trigger and is a software ring buffer.
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
Quite a lot of this program would be simplified if a couple
of generic library routines were available. It also illustrates
the necessary separation between user space and kernel space
elements of the IIO headers (cannot currently be used in here
so a couple of things have to be redefined).
Documentation/industrialio/TestRingLIS3L02DQ.c | 340
1 files changed, 340 insertions(+), 0 deletions(-)
diff --git a/Documentation/industrialio/TestRingLIS3L02DQ.c
b/Documentation/industrialio/TestRingLIS3L02DQ.c
new file mode 100644
index 000..e963d61
--- /dev/null
+++ b/Documentation/industrialio/TestRingLIS3L02DQ.c
@@ -0,0 +1,340 @@
+/* Industrialio test ring buffer for lis3l02dq
+ *
+ * Copyright (c) 2008 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * There are numerous places where this code could be shortened but that
+ * is work for another day. The basic principles are what matter at
+ * this stage.
+ */
+#include dirent.h
+#include fcntl.h
+#include stdio.h
+#include errno.h
+#include stdint.h
+#include linux/types.h
+#include sys/stat.h
+#include sys/dir.h
+
+/* FIXME: Get this from main headers - Separation into userspace
+ * accessible parts and kernel only parts still needs to be done.
+ */
+struct iio_event_data {
+ int id;
+ __s64 timestamp;
+};
+
+#define IIO_EVENT_CODE_RING_50_FULL 200
+#define IIO_EVENT_CODE_RING_75_FULL 201
+#define IIO_EVENT_CODE_RING_100_FULL 202
+/* Returns the base device directory of a named sensor.
+ * This sort of useful function should go in a generic userspace
+ * library */
+char *find_device_by_name(const char *name)
+{
+ const char *iio_dir = /sys/class/industrialio;
+ const struct dirent *ent;
+ int cnt, pos, pos2;
+ FILE *nameFile;
+ DIR *dp;
+ char thisname[100];
+ char temp[100];
+
+ char *returnstring = NULL;
+ struct stat Stat;
+ pos = sprintf(temp, %s, iio_dir);
+ pos += sprintf(temp + pos, /);
+ dp = opendir(iio_dir);
+ if (dp == NULL) {
+ printf(No industrialio devices available);
+ return NULL;
+ }
+ while (ent = readdir(dp), ent != NULL) {
+ cnt++;
+ /*reject . and .. */
+ if (strcmp(ent-d_name, .) != 0
+ strcmp(ent-d_name, ..) != 0) {
+ /*make sure it isn't a trigger!*/
+ if (strncmp(ent-d_name, iio_trigger, 10) != 0) {
+ /* build full path to new file */
+ pos2 = pos + sprintf(temp+pos, %s/,
+ent-d_name);
+ sprintf(temp+pos2, name);
+ printf(search location %s\n, temp);
+ nameFile = fopen(temp, r);
+ if (!nameFile) {
+ sprintf(temp + pos2, modalias,
+ ent-d_name);
+ nameFile = fopen(temp, r);
+ if (!nameFile) {
+ printf(Failed to find name\n);
+ return NULL;
+ }
+ }
+ fscanf(nameFile, %s, thisname);
+ if (strcmp(name, thisname) == 0) {
+ returnstring = malloc(strlen(temp) + 1);
+ sprintf(temp + pos2, );
+ strcpy(returnstring, temp);
+ return returnstring;
+ }
+ fclose(nameFile);
+
+ }
+ }
+ }
+}
+
+int RingLength = 100;
+int NumVals = 3;
+
+int main(int argc, char **argv)
+{
+ int toread, sample = 0;
+ uint16_t tempx, tempy, tempz;
+ FILE *sysfsfp, *fp_ev, *ringcont;
+ int fp;
+ char *data;
+ const char *device_name = lis3l02dq;
+ size_t read_size;
+ int i, j, k, temps;
+ int minor, minor_ev;
+ char name_chrdevevt[100];
+ char name_chrdevring[100];
+ char command[100];
+ int device_no;
+ char temp[200];
+ int pos;
+ struct iio_event_data dat;
+ int scanx = 1, scany = 1, scanz = 1;
+ int scants
Re: [spi-devel-general] [Industrial I/O] [0/13] RFC: IIO v3 patchset
have both functions. The sort of devices we are talking typically communicate over I2C or SPI buses though drivers for rs232 devices etc are definitely on the cards. Basically we are interested in devices where direct memory mapped access is not possible. We have I2C and SPI drivers so I assume you will use the lower layers of the stacks to do this ? For discussion of why these don't fit within existing subsystems see http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. I don't see much there which says why you can't unify all this in a user space library. For RS232/423/.. devices you can go this path if you want (but I would keep it all in userspace anyway) as you can use a line discipline to sit on top of the port and provide another interface (eg the way PPP does) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
