Jonathan Cameron [Tue, 18 Aug 2009 17:06:30 +0000 (18:06 +0100)]
Staging: IIO: Periodic timer based trigger
The original posting of this driver led to a discussion in
which it was commented that a better system was needed
for dealing with the many possible periodic interrupt
sources available on some SoCs. Unfortunately that is
a big task and as far as I know, no-one has taken it
on as yet. So in the meantime this driver is still
in here.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Tue, 18 Aug 2009 17:06:28 +0000 (18:06 +0100)]
Staging: IIO: lis3l02dq ring buffer and data ready trigger support
Example of relatively common case of device sampling
based on internal clock and providing a data ready
signal to indicate that new data is available to be
read out.
Generic trigger approach used to allow other devices
to be sampled 'at the same time' as this the accelerometer.
This is very useful in various motion estimation algorithms.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Tue, 18 Aug 2009 17:06:27 +0000 (18:06 +0100)]
Staging: IIO: Ring buffer: Initial pass at rarely locked ring buffer
Please note this ring buffer implementation is very much a
work in progress (and hence RFC). In it's current form
it is stable and reasonably efficient. There are a couple
of unlikely cases that will lead to more data being lost
that is strictly necessary. The target was for the case
of requiring regular sampling even during user space reads.
All comments welcome.
The intention is to make this only one of several
implementations with run time selection. For now there
is only one, so it is hard coded into the drivers using it.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Tue, 18 Aug 2009 17:06:26 +0000 (18:06 +0100)]
Staging: IIO: Trigger support added to core.
Add general registration support for IIO triggers. These
are currently only used to initialize a 'poll' of a given
device. Examples include the lis3l02dq's data ready signal
being used to initialize a read and gpio triggers being
used to allow externally synchronized sensor reading.
Each trigger can cause any number of 'consumer' devices
to be polled with each storing data into a related ring
buffer.
Two stage triggering is supported with 'fast' and 'slow'
paths. The first is used for things like pulling a data
hold line high and the second for actual read which
may take far longer.
Changes since V2:
* As with IIO triggers now use a registration approach
much closer to that of input leading to cleaner code.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Tue, 18 Aug 2009 17:06:24 +0000 (18:06 +0100)]
Staging: IIO: Add generic ring buffer support to the IIO core
This provides a unified interface for hardware and software
ring buffers.
Changes since V2:
* Moved to a more consistent structure. Now the ring buffer
has an associated struct device which is a child of the
relevant iio_dev. This in turn has two children, one
for the event interface and one for the access interface.
These two interfaces are now managed via cdev structures.
* Numerous minor cleanups
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Tue, 18 Aug 2009 17:06:23 +0000 (18:06 +0100)]
Staging: IIO: kxsd9 accelerometer minimal support
This provides only very minimal support for this device.
Note that an alternate driver has been posted to the input
mailing list.
When the original LMKL discussion that led to the descision
to develop IIO occured, the question on whether the differing
requirements of IIO and input drivers made it a good idea
to have unified drivers was left as an open question.
It still is. All opinions on this question welcome.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Julia Lawall [Fri, 14 Aug 2009 20:10:00 +0000 (22:10 +0200)]
staging: Make some structures static
This was done using a semantic patch (http://coccinelle.lip6.fr/) that
checks that the declaration is not inside a function definition, that the
defined variable is not exported using EXPORTED_SYMBOL, etc, and that the
defined variable does not occur in any other file. If these conditions
hold, static is added before the declaration.
Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* remove RT30xx ifdefs
* add -DRT3070 to rt2870's EXTRA_CFLAGS
* because of changes in the way that hardware is initialized/accessed
rt3070 driver's firmware should be now also used by rt2870 driver
(this is also done by newer out-of-tree vendor driver versions, i.e.
2.1.0.0, historically in-kernel driver was based on 1.4.0.0 version)
* change RT28xx_CHIP_NAME to RTxx70
* update rt2870's help entry text
* add MODULE_ALIAS("rt3070sta") to rt2870
* update rt3070's dependencies
* add !RT30xx version of IS_RT3090() macro
* remove superfluous RT30xx ifdefs
* unify RT30xx and !RT30xx code where possible
* kill RT28XX_UPDATE_PROTECT() macro
* remove needless variable initializations
* kill some needless function prototypes
In file included from drivers/staging/rt3070/common/../../rt2870/common/cmm_data.c:2,
from drivers/staging/rt3070/common/cmm_data.c:2:
drivers/staging/rt3070/common/../../rt2870/common/../../rt2860/common/cmm_data.c: In function ‘RTMP_FillTxBlkInfo’:
drivers/staging/rt3070/common/../../rt2870/common/../../rt2860/common/cmm_data.c:1018: warning: label ‘FillTxBlkErr’ defined but not used
In file included from drivers/staging/rt3070/common/../../rt2870/common/eeprom.c:2,
from drivers/staging/rt3070/common/eeprom.c:2:
drivers/staging/rt3070/common/../../rt2870/common/../../rt2860/common/eeprom.c: In function ‘set_eFuseLoadFromBin_Proc’:
drivers/staging/rt3070/common/../../rt2870/common/../../rt2860/common/eeprom.c:1041: warning: unused variable â\80\98orgfsgidâ\80\99
drivers/staging/rt3070/common/../../rt2870/common/../../rt2860/common/eeprom.c:1041: warning: unused variable ‘orgfsuid’
In file included from drivers/staging/rt3070/../rt2870/rt_profile.c:2,
from drivers/staging/rt3070/rt_profile.c:2:
drivers/staging/rt3070/../rt2870/../rt2860/rt_profile.c: In function ‘RTMPReadParametersHook’:
drivers/staging/rt3070/../rt2870/../rt2860/rt_profile.c:863: warning: unused variable â\80\98orgfsgidâ\80\99
drivers/staging/rt3070/../rt2870/../rt2860/rt_profile.c:863: warning: unused variable â\80\98orgfsuidâ\80\99
In file included from drivers/staging/rt3070/common/rtusb_io.c:2:
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c: In function ‘CMDHandler’:
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1763: warning: ‘CipherAlg’ may be used uninitialized in this function
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1758: note: ‘CipherAlg’ was declared here
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1763: warning: ‘KeyIdx’ may be used uninitialized in this function
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1757: note: ‘KeyIdx’ was declared here
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1763: warning: ‘ApIdx’ may be used uninitialized in this function
drivers/staging/rt3070/common/../../rt2870/common/rtusb_io.c:1759: note: ‘ApIdx’ was declared here
David Rowe [Sun, 23 Aug 2009 01:27:53 +0000 (10:57 +0930)]
Staging: echo: top bit patch
This patch removes the need for the bit_operations.h include file which
can now be deleted. It also contains some minor corrections to comments
(typos and alignment of ASCII formulas). I have also removed some #if
lines that were not necessary.
I have tested the patch using a unit test module that runs in kernel
mode and have verified that the patched code gives identical results to
the previous version using a 8000 sample input sequence. Let me know if
you want this unit test, it runs automatically when the module is
insmod-ed and outputs a go/no go result:
# insmod oslec.ko
# dmesg
[17191803.480000] oslec_test installed
[17191803.480000] Testing OSLEC with 128 taps (16 ms tail)
[17191803.496000] Oslec Unit Test PASSED! pass: 8000 fail: 0
Signed-off-by: David Rowe <david@rowetel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kamalesh Babulal [Fri, 14 Aug 2009 10:22:50 +0000 (15:52 +0530)]
Staging: sep: SEP driver build breaks with CONFIG_PCI=n
next-20090813 randconfig build breaks Discretix SEP driver when
configured with CONFIG_PCI=n.
drivers/staging/sep/sep_driver.c: In function 'sep_probe':
drivers/staging/sep/sep_driver.c:2548: error: implicit declaration of function 'pci_dev_get'
This patch adds the dependency on PCI for the DX SEP driver.
Alan Cox [Fri, 14 Aug 2009 14:49:22 +0000 (15:49 +0100)]
Staging: sep: untangle the register_fs code
While goto can be useful for cleaner cleaning up in C (as Linux sometimes
does and I think Linus borrowed stylistically from Amiga) you can overdo it.
Here is a fine fine example of when it's overkill
Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / linux-beck.git / log