- 15 Sep, 2009 40 commits
-
-
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 <jic23@cam.ac.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
-
Jonathan Cameron authored
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 authored
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 authored
This is a pretty minimalist example of an IIO driver. Signed-off-by:
-
Jonathan Cameron authored
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 authored
Signed-off-by:
-
Julia Lawall authored
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:
-
Ben Hutchings authored
Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Roel Kluin authored
The test always evaluated to true. MIN_FRAG_THRESHOLD is defined 256, MAX_FRAG_THRESHOLD is defined 2346 Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
rt2870 handles now all rt2870/rt3070 chipsets. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
* 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 Signed-off-by: -
Bartlomiej Zolnierkiewicz authored
rt3070: * remove non-working AntDiversity config parameter * remove unused bRxAntDiversity field from COMMON_CONFIG rt2870: * propagate Antenna Diversity support from rt3070 Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
rt3070: * remove unused bEEPROMFile field from RTMP_ADAPTER rt2870: * propagate eFuse support from rt3070 Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Then remove no longer needed MlmeDataHardTransmit(). Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
* remove write-only EFuseTag field from RTMP_ADAPTER * remove needless EFUSE_TAG register read Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Propagate WEP fixes from rt28[67]0 to rt3070. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
rt3070 driver allows use of 5G channel 34 while rt{286,287,309}0 drivers don't and quick googling seems to confirm the limitation. Signed-off-by:
-
