| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
same device
Some triggers can only be attached to the IIO device that corresponds to
the same physical device. Currently each driver that requires this
implements its own trigger validation function.
Introduce a new helper function called iio_trigger_validate_own_device()
that can be used to do this check. Having a common implementation avoids
code duplication and unnecessary boiler-plate code.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
This adds a helper function to the IIO trigger framework:
iio_trigger_using_own(): for an IIO device, this tells
whether the device is using itself as a trigger.
This is true if the indio device:
(A) supplies a trigger and
(B) has assigned its own buffer poll function to use this
trigger.
This helper function is good when constructing triggered,
buffered drivers that can either use its own hardware *OR*
an external trigger such as a HRTimer or even the trigger from
a totally different sensor.
Under such circumstances it is important to know for example
if the timestamp from the same trigger hardware should be used
when populating the buffer: if iio_trigger_using_own() is true,
we can use this timestamp, else we need to pick a unique
timestamp directly in the trigger handler.
For this to work of course IIO devices registering hardware
triggers must follow the convention to set the parent device
properly, as as well as setting the parent of the IIO device
itself.
When a new poll function is attached, we check if the parent
device of the IIO of the poll function is the same as the
parent device of the trigger and in that case we conclude that
the hardware is using itself as trigger.
Cc: Giuseppe Barba <[email protected]>
Cc: Denis Ciocca <[email protected]>
Cc: Crestez Dan Leonard <[email protected]>
Cc: Gregor Boirie <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Add resource managed devm_iio_trigger_register() and
devm_iio_triger_unregister() to automatically clean up registered triggers
allocated by IIO drivers, thus leading to simplified IIO drivers code.
Signed-off-by: Gregor Boirie <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
There are times when an assigned trigger to a device shouldn't ever
change after intialization.
Examples of this being used is when an provider device has a trigger
that is assigned to an ADC, which uses it populate data into a callback
buffer.
Signed-off-by: Matt Ranostay <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
When compile iio related driver the following warning shown:
include/linux/iio/trigger.h:35:34: warning: 'struct iio_trigger'
declared inside parameter list
int (*set_trigger_state)(struct iio_trigger *trig, bool state);
include/linux/iio/trigger.h:38:18: warning: 'struct iio_dev'
declared inside parameter list
struct iio_dev *indio_dev);
'struct iio_dev' and 'struct iio_trigger' was used before declaration,
forward declaration for these structs to fix warning.
Signed-off-by: Pengyu Ma <[email protected]>
Acked-by: Daniel Baluta <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Instead of a void function, return the trigger pointer.
Whilst not in of itself a fix, this makes the following set of
7 fixes cleaner than they would otherwise be.
Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Cc: [email protected]
|
|
iio_trigger_poll_chained()
argument has been ignored; adjust drivers accordingly
Signed-off-by: Peter Meerwald <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
When using more than one trigger consumer it can happen that multiple threads
perform a read-modify-update cycle on 'use_count' concurrently. This can cause
updates to be lost and use_count can get stuck at non-zero value, in which case
the IIO core assumes that at least one thread is still running and will wait for
it to finish before running any trigger handlers again. This effectively renders
the trigger disabled and a reboot is necessary before it can be used again. To
fix this make use_count an atomic variable. Also set it to the number of
consumers before starting the first consumer, otherwise it might happen that
use_count drops to 0 even though not all consumers have been run yet.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Tested-by: Denis Ciocca <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Use dev_{set,get}_drvdata for managing private data attached to a trigger
instead of using a custom field in the iio_trigger struct.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Introduce iio_tigger_{set,get}_drvdata which allows to attach driver specific
data to a trigger. The functions wrap access to the triggers private_data field
and all current users are updated to use iio_tigger_{set,get}_drvdata instead of
directly accessing the private_data field. This is the first step towards
removing the private_data field from the iio_trigger struct.
The following coccinelle script has been used to update the drivers:
<smpl>
@@
struct iio_trigger *trigger;
expression priv;
@@
-trigger->private_data = priv
+iio_trigger_set_drv_data(trigger, priv)
@@
struct iio_trigger *trigger;
@@
-trigger->private_data
+iio_trigger_get_drv_data(trigger)
</smpl>
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Also include a couple of forward defs of struct iio_trigger and struct
iio_trigger_ops to avoid doing this in each driver.
Signed-off-by: Jonathan Cameron <[email protected]>
Reported-by: Randy Dunlap <[email protected]>
Acked-by: Denis Ciocca <[email protected]>
|
|
Signed-off-by: Peter Meerwald <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Signed-off-by: Peter Meerwald <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
Currently we use two different naming schemes in the IIO API, iio_verb_object
and iio_object_verb. E.g iio_device_register and iio_allocate_device. This
patches renames instances of the later to the former. The patch also renames allocate to
alloc as this seems to be the preferred form throughout the kernel.
In particular the following renames are performed by the patch:
iio_put_device -> iio_device_put
iio_allocate_device -> iio_device_alloc
iio_free_device -> iio_device_free
iio_get_trigger -> iio_trigger_get
iio_put_trigger -> iio_trigger_put
iio_allocate_trigger -> iio_trigger_alloc
iio_free_trigger -> iio_trigger_free
The conversion was done with the following coccinelle patch with manual fixes to
comments and documentation.
<smpl>
@@
@@
-iio_put_device
+iio_device_put
@@
@@
-iio_allocate_device
+iio_device_alloc
@@
@@
-iio_free_device
+iio_device_free
@@
@@
-iio_get_trigger
+iio_trigger_get
@@
@@
-iio_put_trigger
+iio_trigger_put
@@
@@
-iio_allocate_trigger
+iio_trigger_alloc
@@
@@
-iio_free_trigger
+iio_trigger_free
</smpl>
Signed-off-by: Lars-Peter Clausen <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Step 1 in moving the IIO core out of staging.
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|