17 Oct, 2013
1 commit
-
The functionality implemented by iio_sw_buffer_preenable() is now done directly
in the IIO core and previous users of iio_sw_buffer_preenable() have all been
updated to not use it anymore. It is unused now and can be remove.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
12 Oct, 2013
3 commits
-
For some devices it is possible to configure a hysteresis for threshold (or
similar) events. This patch adds a new hysteresis event info type which allows
for easy creation and read/write handling of the sysfs attribute.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
The event configuration interface of the IIO framework has not been getting the
same attention as other parts. As a result it has not seen the same improvements
as e.g. the channel interface has seen with the introduction of the channel spec
struct. Currently all the event config callbacks take a u64 (the so called event
code) to pass all the different information about for which event the callback
is invoked. The callback function then has to extract the information it is
interested in using some macros with rather long names. Most information encoded
in the event code comes straight from the iio_chan_spec struct the event was
registered for. Since we always have a handle to the channel spec when we call
the event callbacks the first step is to add the channel spec as a parameter to
the event callbacks. The two remaining things encoded in the event code are the
type and direction of the event. Instead of passing them in one parameter, add
one parameter for each of them and remove the eventcode from the event
callbacks. The patch also adds a new iio_event_info parameter to the
{read,write}_event_value callbacks. This makes it possible, similar to the
iio_chan_info_enum for channels, to specify additional properties other than
just the value for an event. Furthermore the new interface will allow to
register shared events. This is e.g. useful if a device allows configuring a
threshold event, but the threshold setting is the same for all channels.To implement this the patch adds a new iio_event_spec struct which is similar to
the iio_chan_spec struct. It as two field to specify the type and the direction
of the event. Furthermore it has a mask field for each one of the different
iio_shared_by types. These mask fields holds which kind of attributes should be
registered for the event. Creation of the attributes follows the same rules as
the for the channel attributes. E.g. for the separate_mask there will be a
attribute for each channel with this event, for the shared_by_type there will
only be one attribute per channel type. The iio_chan_spec struct gets two new
fields, 'event_spec' and 'num_event_specs', which is used to specify which the
events for this channel. These two fields are going to replace the channel's
event_mask field.For now both the old and the new event config interface coexist, but over the
few patches all drivers will be converted from the old to the new interface.
Once that is done all code for supporting the old interface will be removed.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
Since the buffer is accessed by userspace we can not just free the buffers
memory once we are done with it in kernel space. There might still be open file
descriptors and userspace still might be accessing the buffer. This patch adds
support for reference counting to the IIO buffers. When a buffer is created and
initialized its initial reference count is set to 1. Instead of freeing the
memory of the buffer the buffer's _free() function will drop that reference
again. But only after the last reference to the buffer has been dropped the
buffer the buffer's memory will be freed. The IIO device will take a reference
to its primary buffer. The patch adds a small helper function for this called
iio_device_attach_buffer() which will get a reference to the buffer and assign
the buffer to the IIO device. This function must be used instead of assigning
the buffer to the device by hand. The reference is only dropped once the IIO
device is freed and we can be sure that there are no more open file handles. A
reference to a buffer will also be taken whenever the buffer is active to avoid
the buffer being freed while data is still being send to it.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
24 Sep, 2013
2 commits
-
The power to some of the sensors are controlled by regulators. In most
cases these are 'always on', but if not they will fail to work until
the regulator is enabled using the relevant APIs. This patch allows for
the Vdd_IO power supply to be specified by either platform data or
Device Tree.Signed-off-by: Lee Jones
Signed-off-by: Jonathan Cameron -
The power to some of the sensors are controlled by regulators. In most
cases these are 'always on', but if not they will fail to work until
the regulator is enabled using the relevant APIs. This patch allows for
the Vdd power supply to be specified by either platform data or Device
Tree.Signed-off-by: Lee Jones
Signed-off-by: Jonathan Cameron
22 Sep, 2013
1 commit
-
Drivers using software buffers often store the timestamp in their data buffer
before calling iio_push_to_buffers() with that data buffer. Storing the
timestamp in the buffer usually involves some ugly pointer arithmetic. This
patch adds a new helper function called iio_push_buffers_with_timestamp() which
is similar to iio_push_to_buffers but takes an additional timestamp parameter.
The function will help to hide to uglyness in one central place instead of
exposing it in every driver. If timestamps are enabled for the IIO device
iio_push_buffers_with_timestamp() will store the timestamp as the last element
in buffer, before passing the buffer on to iio_push_buffers(). The buffer needs
large enough to hold the timestamp in this case. If timestamps are disabled
iio_push_buffers_with_timestamp() will behave just like iio_push_buffers().Signed-off-by: Lars-Peter Clausen
Cc: Oleksandr Kravchenko
Cc: Josh Wu
Cc: Denis Ciocca
Cc: Manuel Stahl
Cc: Ge Gao
Cc: Peter Meerwald
Cc: Jacek Anaszewski
Cc: Fabio Estevam
Cc: Marek Vasut
Signed-off-by: Jonathan Cameron
16 Sep, 2013
4 commits
-
Change the type of the 'data' parameter for iio_push_to_buffers() from 'u8 *' to
'const void *'. Drivers typically use the correct type (e.g. __be16 *) for their
data buffer. When passing the buffer to iio_push_to_buffers() it needs to be
cast to 'u8 *' for the compiler to not complain (and also having to add __force
if we want to keep sparse happy as well). Since the buffer implementation should
not care about the data layout (except the size of one sample) using a void
pointer is the correct thing to do. Also make it const as the buffer
implementations are not supposed to modify it.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
These two additional info_mask bitmaps should allow all 'standard'
numeric attributes to be handled using the read_raw and write_raw
callbacks. Whilst this should reduce code, the more important element
is that this makes these values easily accessible to in kernel users
of IIO devices.Signed-off-by: Jonathan Cameron
Reviewed-by: Lars-Peter Clausen -
Introduce an enum to specify whether the attribute is separate or
shared.Factor out the bitmap handling for loop into a separate function.
Tidy up error handling and add a NULL assignment to squish a false
positive warning from GCC.Change ext_info shared type from boolean to enum and update in all
drivers.Signed-off-by: Jonathan Cameron
Reviewed-by: Lars-Peter Clausen -
Somehow this got missed when dropping all the code that used it
prior to the split. Remove it now, there are no users.Signed-off-by: Jonathan Cameron
Reviewed-by: Lars-Peter Clausen
15 Sep, 2013
2 commits
-
At the moment the number of channels specified is dictated by the first
sensor supported by the driver. As we add support for more sensors this
is likely to vary. Instead of using the ARRAY_SIZE() of the LPS331AP's
channel specifier we'll use a new adaptable 'struct st_sensors' element
instead.Signed-off-by: Lee Jones
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron -
Integration time is in seconds; it controls the measurement
time and influences the gain of a sensor.There are two typical ways that scaling is implemented in a device:
1) input amplifier,
2) reference to the ADC is changed.
These both result in the accuracy of the ADC varying (by applying its
sampling over a more relevant range).Integration time is a way of dealing with noise inherent in the analog
sensor itself. In the case of a light sensor, a mixture of photon noise
and device specific noise. Photon noise is dealt with by either improving
the efficiency of the sensor, (more photons actually captured) which is not
easily varied dynamically, or by integrating the measurement over a longer
time period. Note that this can also be thought of as an averaging of a
number of individual samples and is infact sometimes implemented this way.
Altering integration time implies that the duration of a measurement changes,
a fact the device's user may be interested in.Hence it makes sense to distinguish between integration time and simple
scale. In some devices both types of control are present and whilst they
will have similar effects on the amplitude of the reading, their effect
on the noise of the measurements will differ considerably.Used by adjd_s311, tsl4531, tcs3472
The following drivers have similar controls (and could be adapted):
* tsl2563 (integration time is controlled via CALIBSCALE among other things)
* tsl2583 (has integration_time device_attr, but driver doesn't use channels yet)
* tsl2x7x (has integration_time attr)Signed-off-by: Peter Meerwald
Cc: Jon Brenner
Signed-off-by: Jonathan Cameron
01 Sep, 2013
1 commit
-
Signed-off-by: Peter Meerwald
Signed-off-by: Jonathan Cameron
18 Aug, 2013
1 commit
-
Add a resource managed devm_iio_trigger_alloc()/devm_iio_triger_free()
to automatically clean up triggers allocated by IIO drivers, thus
leading to simplified IIO drivers code.Signed-off-by: Jacek Anaszewski
Signed-off-by: Kyunmin Park
Signed-off-by: Jonathan Cameron
13 Aug, 2013
1 commit
-
We want the staging fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
04 Aug, 2013
4 commits
-
Signed-off-by: Peter Meerwald
Cc: Grygorii Strashko
Cc: Oleksandr Kravchenko
Signed-off-by: Jonathan Cameron -
Add a resource managed devm_iio_device_alloc()/devm_iio_device_free()
to automatically clean up any allocations made by IIO drivers,
thus leading to simplified IIO drivers code.In addition, this will allow IIO drivers to use other devm_*() API
(like devm_request_irq) and don't care about the race between
iio_device_free() and the release of resources by Device core
during driver removing.Signed-off-by: Grygorii Strashko
Signed-off-by: Oleksandr Kravchenko
Tested-by: Oleksandr Kravchenko
Reviewed-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
There are no users of this macro left and we have come to the conclusion that it
is not a good idea to expose the raw chip reset to userspace so the macro is
very unlikely to be used in new drivers.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
This patch add support to redirect the DRDY interrupt on INT1 or INT2
on accelerometer and pressure sensors.Signed-off-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
20 Jul, 2013
1 commit
-
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
Tested-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
03 Jul, 2013
1 commit
-
Since the info_mask split, iio_channel_has_info() is not working correctly.
info_mask_separate and info_mask_shared_by_type, it is not possible to compare
them directly with the iio_chan_info_enum enum. Correct that bit using the BIT()
macro.Cc: # 3.10.x
Signed-off-by: Alexandre Belloni
Signed-off-by: Jonathan Cameron
06 Jun, 2013
1 commit
-
…nd added support on one-shot sysfs reads to 3 byte channel
This patch introduce num_data_channels variable on st_sensors struct
to manage different type of channels (size or number) in
st_sensors_get_buffer_element function.
Removed ST_SENSORS_NUMBER_DATA_CHANNELS and ST_SENSORS_BYTE_FOR_CHANNEL
and used struct iio_chan_spec const *ch to catch data.
Added 3 byte channel data support on one-shot reads.Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
05 Jun, 2013
2 commits
-
Signed-off-by: Denis Ciocca
Signed-off-by: Jonathan Cameron -
Signed-off-by: Michael Hennerich
Reviewed-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
01 May, 2013
1 commit
-
Pull trivial tree updates from Jiri Kosina:
"Usual stuff, mostly comment fixes, typo fixes, printk fixes and small
code cleanups"* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (45 commits)
mm: Convert print_symbol to %pSR
gfs2: Convert print_symbol to %pSR
m32r: Convert print_symbol to %pSR
iostats.txt: add easy-to-find description for field 6
x86 cmpxchg.h: fix wrong comment
treewide: Fix typo in printk and comments
doc: devicetree: Fix various typos
docbook: fix 8250 naming in device-drivers
pata_pdc2027x: Fix compiler warning
treewide: Fix typo in printks
mei: Fix comments in drivers/misc/mei
treewide: Fix typos in kernel messages
pm44xx: Fix comment for "CONFIG_CPU_IDLE"
doc: Fix typo "CONFIG_CGROUP_CGROUP_MEMCG_SWAP"
mmzone: correct "pags" to "pages" in comment.
kernel-parameters: remove outdated 'noresidual' parameter
Remove spurious _H suffixes from ifdef comments
sound: Remove stray pluses from Kconfig file
radio-shark: Fix printk "CONFIG_LED_CLASS"
doc: put proper reference to CONFIG_MODULE_SIG_ENFORCE
...
26 Mar, 2013
3 commits
-
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
Signed-off-by: Jonathan Cameron -
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:
@@
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)Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron -
…/iio into staging-next
Jonathan writes:
First set of IIO new drivers and cleanup for the 3.10 cycle.
New stuff
1) Add OF support for specifying mappings between iio devices and their
in kernel consumers.
2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and
ad7924 added later in series)
3) Driver for Exynos adc (dt suppor for phy added later in series).
4) Make iio_push_event save IRQ context - necessary if it is to be used
within an interrupt handler. Users of this functionality to follow.
5) For iio use the device tree node name to provide the hwmon name attribute
if available.Removal and moves out of staging
1) Drop the adt7410 driver from IIO now that there is a hmwon driver with
equivalent support. This device is very much targeted at hardware
monitoring so hwmon is a more appropriate host for the driver.
2) Move iio_hwmon driver to drivers/hwmon.Cleanups
1) Minor cleanup in ST common library.
2) Large set of patches to break the info_mask element which previously used
odd and even bits to specify if a channel attribute was either shared across
similar channels or specific to only one. Now we have two bitmaps, one for
those parameters that are specific to this channel and one for those shared
by all channels with the same type as this one. This has no effect on the
userspace abi. It simplifies the core code and provides more space for new
channel parameters. It has been on the todo list for a long time!Conflicts:
drivers/iio/dac/ad5064.c
18 Mar, 2013
6 commits
-
Signed-off-by: Paul Bolle
Signed-off-by: Jiri Kosina -
This has been replaced by the pair of masks info_mask_separate
and info_mask_shared_by_type. Other variants may follow.Signed-off-by: Jonathan Cameron
Acked-by: Lars-Peter Clausen -
The original info_mask is going away in favour of the broken out versions.
Signed-off-by: Jonathan Cameron
Acked-by: Lars-Peter Clausen -
The original info_mask is going away in favour of the broken out versions.
Signed-off-by: Jonathan Cameron
Acked-by: Lars-Peter Clausen -
The original info_mask is going away in favour of the broken out versions.
Signed-off-by: Jonathan Cameron
Acked-by: Denis Ciocca -
This simplifies the code, removes an extensive layer of 'helper' macros
and gives us twice as much room to play with in these masks before we
have any need to be clever.Signed-off-by: Jonathan Cameron
Acked-by: Lars-Peter Clausen
03 Mar, 2013
1 commit
-
If CONFIG_IIO_TRIGGER is defined but CONFIG_IIO_BUFFER is not, the following
build error is seen.drivers/iio/common/st_sensors/st_sensors_trigger.c:21:5: error:
redefinition of ‘st_sensors_allocate_trigger’
In file included from
drivers/iio/common/st_sensors/st_sensors_trigger.c:18:0:
include/linux/iio/common/st_sensors.h:239:19: note: previous
definition of ‘st_sensors_allocate_trigger’ was here
drivers/iio/common/st_sensors/st_sensors_trigger.c:65:6: error:
redefinition of ‘st_sensors_deallocate_trigger’
In file included from
drivers/iio/common/st_sensors/st_sensors_trigger.c:18:0:
include/linux/iio/common/st_sensors.h:244:20: note: previous
definition of ‘st_sensors_deallocate_trigger’ was hereThis occurs because st_sensors_deallocate_trigger is built if CONFIG_IIO_TRIGGER
is defined, but the dummy function is compiled if CONFIG_IIO_BUFFER is defined.Signed-off-by: Guenter Roeck
Acked-by: Denis Ciocca
Signed-off-by: Jonathan Cameron
09 Feb, 2013
2 commits
-
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
Reported-by: Randy Dunlap
Acked-by: Denis Ciocca -
This patch resolve a bugfix when driver is compiled without trigger.
Signed-off-by: Denis Ciocca
Reported-by: Randy Dunlap
Signed-off-by: Jonathan Cameron
07 Feb, 2013
1 commit
-
For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.Signed-off-by: Guenter Roeck
Acked-by: Anton Vorontsov
Acked-by: Chanwoo Choi
Signed-off-by: Jonathan Cameron
02 Feb, 2013
1 commit
-
Instead of requiring the map to unregister, simply unregister all map entries
associated with the given iio device. This simplifies map removal and also works
for maps generated through devicetree.Signed-off-by: Guenter Roeck
Signed-off-by: Jonathan Cameron