- 15 Sep, 2009 40 commits
-
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
We only read eeprom id 0, in byte mode - so the rest can go away Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
bOverrideAddress is write only so kill it rather than fix it Signed-off-by:
-
Alan Cox authored
No point having a file just for that Signed-off-by:
-
Alan Cox authored
Adapter was cleared by netdev allocation so any zero defaults do not need writing. Signed-off-by:
-
Alan Cox authored
Prune this back as most of it isn't relevant or used Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
One writer, of a constant, one user .. it can go. Signed-off-by:
-
Alan Cox authored
Switch this to a Linux like naming as it occurs all over. Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
They are all in the pcidev anyway plus are not used by the code Signed-off-by:
-
Alan Cox authored
Most are unused, one is used and can be replaced with the definition Signed-off-by:
-
Alan Cox authored
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 authored
Signed-off-by:
-
Alan Cox authored
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 authored
Switch to the more normal "flags" naming. Also fix up the nested use of spin_lock_irqsave Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
atomic_long != atomic Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Randy Dunlap authored
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:
-
Alan Cox authored
Signed-off-by:
-
Jonathan Cameron authored
Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Jonathan Cameron authored
This needs considerably more work, all comments / suggestions welcomed. Signed-off-by:
-
Jonathan Cameron authored
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 authored
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 authored
Changes since V2: * Moved to new registration methodology. Signed-off-by:
-
Jonathan Cameron authored
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 authored
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 authored
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 authored
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 authored
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:
-
