We have two trivial IRQ routines, a single statement and a real function -
relocate them. While we are at it kill the trivial to sort out soft reset
and slv bits in the same areas of code.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We only read eeprom id 0, in byte mode - so the rest can go away
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bOverrideAddress is write only so kill it rather than fix it
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adapter was cleared by netdev allocation so any zero defaults do not need
writing.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Switch this to a Linux like naming as it occurs all over.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
They are all in the pcidev anyway plus are not used by the code
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Most are unused, one is used and can be replaced with the definition
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The RefCount field is accessed only by a macro and the only use of it in
the tree is to read it, so it can go
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is assigned once to ndis d0, and then never changes so it is a constant
and we can zap it
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Switch to the more normal "flags" naming. Also fix up the nested use of
spin_lock_irqsave
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
device attr's should be static, otherwise duplicate identifiers are
created:
drivers/staging/iio/trigger/iio-trig-gpio.o:(.data+0x1c): multiple definition of `dev_attr_name'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This needs considerably more work, all comments / suggestions
welcomed.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Simple example of how a gpio trigger driver would work.
Things to be added include interupt type control (high, low).
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
Changes since V2:
* Moved to new registration methodology.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
Example of how a device with a hardware ring buffer is
handled within IIO.
Changes since V2:
* Moved to new registration functions giving much cleaner
interface.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
A later patch in the series will add data ready triggering
and ring buffer support.
This core patch provides an event interface and sysfs
based reading of values.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is a pretty minimalist example of an IIO driver.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Core support for MAX1361, MAX1362, MAX1363, MAX1364,
MAX1136, MAX1137, MAX1138, MAX1139, MAX1236, MAX1237,
MAX1238, MAX1239.
Ring buffer support later in series.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
