| Age | Commit message (Collapse) | Author |
|---|
|
commit 5d9854eaea776441b38a9a45b4e6879524c4f48c upstream.
This change undo the change done by 'commit 3bec24747446
("iio: hid-sensor-trigger: Change get poll value function order to avoid
sensor properties losing after resume from S3")' as this breaks some
USB/i2c sensor hubs.
Instead of relying on HW for restoring poll and hysteresis, driver stores
and restores on resume (S3). In this way user space modified settings are
not lost for any kind of sensor hub behavior.
In this change, whenever user space modifies sampling frequency or
hysteresis driver will get the feature value from the hub and store in the
per device hid_sensor_common data structure. On resume callback from S3,
system will set the feature to sensor hub, if user space ever modified the
feature value.
Fixes: 3bec24747446 ("iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3")
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Song, Hongyan <hongyan.song@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
sensor properties losing after resume from S3
commit 3bec247474469f769af41e8c80d3a100dd97dd76 upstream.
In function _hid_sensor_power_state(), when hid_sensor_read_poll_value()
is called, sensor's all properties will be updated by the value from
sensor hardware/firmware.
In some implementation, sensor hardware/firmware will do a power cycle
during S3. In this case, after resume, once hid_sensor_read_poll_value()
is called, sensor's all properties which are kept by driver during S3
will be changed to default value.
But instead, if a set feature function is called first, sensor
hardware/firmware will be recovered to the last status. So change the
sensor_hub_set_feature() calling order to behind of set feature function
to avoid sensor properties lose.
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 65e4345c8ef8811bbb4860fe5f2df10646b7f2e1 upstream.
The LIS3LV02 has a special bit that need to be set to get the
read values left aligned. Before this patch we get gibberish
like this:
iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.010042 -0.642688 19155832931907
0.000000 -0.010042 -0.642688 19155858751073
Which is because we read a raw value for 1g as 64 which is
the nominal 1024 for 1g shifted 4 bits to the left by being
right-aligned rather than left aligned.
Since all other sensors are left aligned, add some code to
set the special DAS (data alignment setting) bit to 1 so that
the right value is now read like this:
iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.147095 -10.120135 24761614364956
-0.029419 -0.176514 -10.120135 24761631624540
The scaling was weird as well: we have a gain of 1000 for 1g
and 3000 for 6g. I don't even remember how I came up with the
old values but they are wrong.
Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer")
Cc: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 65c8aea07de11b6507efa175edb44bd8b4488218 upstream.
Using realbits as i2c/spi read len, when that value is not byte aligned
(e.g 12 bits), lead to skip msb part of out data registers.
Fix this taking into account scan_type.shift in addition to
scan_type.realbits as read length:
read_len = DIV_ROUND_UP(realbits + shift, 8)
This fix has been tested on 8, 12, 16, 24 bit sensors
Fixes: e7385de5291e ("iio:st_sensors: align on storagebits boundaries")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
interpretation.
While testing, it was observed that on some platforms the scale value
from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
in the final angular velocity component values to be zeros.
This is caused by insufficient precision of scale value displayed in sysfs.
If the precision is changed to nano from current micro, then this is
sufficient to display the scale value on this platform.
Since this can be a problem for all other HID sensors, increase scale
precision of all HID sensors to nano from current micro.
Results on Yoga 260:
name scale before scale now
--------------------------------------------
gyro_3d 0.000000 0.000000174
als 0.001000 0.001000000
magn_3d 0.000001 0.000001000
accel_3d 0.000009 0.000009806
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
fix scale configuration/parsing for h3lis331dl accel driver
when sensitivity is higher than 1(m/s^2)/digit
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of iio new device support, features and cleanups for the 4.9 cycle.
New device support
* ad8801 dac
- new driver supporting ad8801 and ad8803 DACs.
* adc12138
- new driver supporting TI adc12130/adc12132 and adc12138 ADCs.
* ltc2485 adc
- new driver
* mxc6255
- add support for the mxc6225 part name and fixup the ID check so it works.
* vz89x VOC sensor
- add support for the vz89te part which drops the voc_short channel and adds
CRCs compared to other supported parts.
New features
* core
- immutable triggers. These effectively grant exclusive control over a
trigger. The typical usecase is a device representing an analog part
(perhaps a MUX) that needs to control the sampling of a downstream
ADC.
- resource managed trigger registration and triggered_buffer_init.
- iio_push_event now protected against case of the event interface
registration not having yet occured. Only matters if an interrupt
can occur during this window - might happen on shared interrupt lines.
- helper to let a driver query if the trigger it is using is provided by
itself (using the convention of both device and trigger having the same
parent).
* tools
- iio-utils. Used channel modifier scaling in preference to generic scaling
when both exist.
* at91-adc
- Add support for touchscreen switches closure time needed by some newer
parts.
* stx104
- support the ADC channels on this ADC/DAC board. As these are the primary
feature of the board also move the driver to the iio/adc directory.
* sx9500
- device tree bindings.
Cleanups / Fixes
* ad5755
- fix an off-by-one on devnr limit check (introduced earlier this cycle)
* ad7266
- drop NULL check on devm_regulator_get_optional as it can't return NULL.
* ak8974
- avoid an unused functional warning due to rework in PM core code.
- remove .owner field setting as done by i2c_core.
* ina2xx
- clear out a left over debug field from chip global data.
* hid-sensors
- avoid an unused functional warning due to rework in PM core code.
* maxim-thermocouple
- fix non static symbol warnings.
* ms5611
- fetch and enable regulators unconditionally when they aren't optional.
* sca3000
- whitespace cleanup.
* st_sensors
- fetch and enable regulators unconditionally rather than having them
supported as optional regulators (missunderstanding on my part amongst
others a while back)
- followup to previous patch fixes error checking on the regulators.
- mark symbols static where possible.
- use the 'is it my trigger' help function. This prevents the odd case
of another device triggering from the st-sensors trigger whilst the
st-sensors trigger is itself not using it but rather using say an hrtimer.
* ti-ads1015
- add missing of_node_put.
* vz89x
- rework to all support of new devices.
- prevent reading of a corrupted buffer.
- fixup a return value of 0/1 in a bool returning function.
Address updates
- Vlad Dogaru email address change.
|
|
We need the IIO changes in here for future patches to build on.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The ST sensors can be used as a trigger for its own triggered buffer
but it is also possible to use an external trigger: a HRTimer or
even a different sensor (!) as trigger. In that case we should not
pick the timestamp from our own interrupt top half even if it is
active.
This could practically happen if some other sensor is using the
ST sensor as trigger but the ST sensor itself is using e.g.
an HRTimer as trigger. So the trigger is on, but not used by us.
We used to assume that whenever the hardware interrupt is turned
on, we are using it for our own trigger, but this is an
oversimplification.
Handle this logically by using the iio_trigger_using_own() helper.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We were checking the return code of vdd when we should be checking
vdd_io. My mistake, mea culpa.
Cc: Giuseppe BARBA <giuseppe.barba@st.com>
Reported-by: Giuseppe BARBA <giuseppe.barba@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
According to IIO ABI definition, IIO_PRESSURE data output unit is
kilopascal:
http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio
This patch fix output unit of HID pressure sensor IIO driver from pascal to
kilopascal to follow IIO ABI definition.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We get 2 warnings when biuld kernel with W=1:
drivers/iio/common/st_sensors/st_sensors_trigger.c:69:13: warning: no previous prototype
for 'st_sensors_irq_handler' [-Wmissing-prototypes]
drivers/iio/common/st_sensors/st_sensors_trigger.c:85:13: warning: no previous prototype
for 'st_sensors_irq_thread' [-Wmissing-prototypes]
In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
so this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
A small rework of the PM code in this driver introduced a harmless
warning when CONFIG_PM_SLEEP is not set:
drivers/iio/common/hid-sensors/hid-sensor-trigger.c:212:12: error: 'hid_sensor_resume' defined but not used [-Werror=unused-function]
This removes the #ifdef and instead marks all three PM functions
as __maybe_unused, which covers all possible cases and is harder
to get wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 7f6cf7414538 ("iio: hid-sensors: use asynchronous resume")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
These sensors all have Vdd and Vdd_IO lines. This means the
supplies are *not* optional (optional means that the supply is
optional in the electrical sense, not the software sense)
so we need to get the and enable them at all times.
If the device tree or board file does not define suitable
regulators for the component, it will be substituted by a
dummy regulator, or, if regulators are disabled altogether,
by stubs. There is no need to use the IS_ERR_OR_NULL() check
that is considered harmful.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Some platforms power off sensor hubs during S3 suspend, which will require
longer time to resume. This hurts system resume time, so resume
asynchronously.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Ensure triggered buffering memory accesses are properly aligned on per
channel storagebits boundaries.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Time to finally kill off the venerable (it was one of my first drivers)
lis3l02dq driver in favour of adding support in the st sensors framework.
This does loose us the event support that driver always had, but I think
that will reappear at some point and in the meantime the maintenance
advantages of dropping the 'special' driver for this one part outweigh
the issues.
It's worth noting this part is ancient and I may well be the only person
who still has any on hardware running recent kernels.
It has a few 'quirks'.
- No WAI register so that just became optional.
- A BDU option that really does block updates. Completely.
Whatever you do, you don't get any more data with it set.
It is documented the same as more modern parts but I presume they
are actually clearing for updates after a read of both bytes!
- Fixed scale.
- It's too quick. Even at slowest rate (280Hz) I can't read out fast
enough on my board (stargate 2) to beat new data coming in. Linus'
repeat read patch doesn't help in this case. It just means I get 10
readings before dying... So in reality this will get used with
software triggers only unless someone has this long out of production
device on a quick board.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Leonard Crestez observed the following phenomenon: when using
hard interrupt triggers (the DRDY line coming out of an ST
sensor) sometimes a new value would arrive while reading the
previous value, due to latencies in the system.
We discovered that the ST hardware as far as can be observed
is designed for level interrupts: the DRDY line will be held
asserted as long as there are new values coming. The interrupt
handler should be re-entered until we're out of values to
handle from the sensor.
If interrupts were handled as occurring on the edges (usually
low-to-high) new values could appear and the line be held
asserted after that, and these values would be missed, the
interrupt handler would also lock up as new data was
available, but as no new edges occurs on the DRDY signal,
nothing happens: the edge detector only detects edges.
To counter this, do the following:
- Accept interrupt lines to be flagged as level interrupts
using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line
is marked like this (in the device tree node or ACPI
table or similar) it will be utilized as a level IRQ.
We mark the line with IRQF_ONESHOT and mask the IRQ
while processing a sample, then the top half will be
entered again if new values are available.
- If we are flagged as using edge interrupts with
IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove
IRQF_ONESHOT so that the interrupt line is not
masked while running the thread part of the interrupt.
This way we will never miss an interrupt, then introduce
a loop that polls the data ready registers repeatedly
until no new samples are available, then exit the
interrupt handler. This way we know no new values are
available when the interrupt handler exits and
new (edge) interrupts will be triggered when data arrives.
Take some extra care to update the timestamp in the poll
loop if this happens. The timestamp will not be 100%
perfect, but it will at least be closer to the actual
events. Usually the extra poll loop will handle the new
samples, but once in a blue moon, we get a new IRQ
while exiting the loop, before returning from the
thread IRQ bottom half with IRQ_HANDLED. On these rare
occasions, the removal of IRQF_ONESHOT means the
interrupt will immediately fire again.
- If no interrupt type is indicated from the DT/ACPI,
choose IRQF_TRIGGER_RISING as default, as this is necessary
for legacy boards.
Tested successfully on the LIS331DL and L3G4200D by setting
sampling frequency to 400Hz/800Hz and stressing the system:
extra reads in the threaded interrupt handler occurs.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Adds a new per-device sysfs attribute "current_timestamp_clock" to allow
userspace to select a particular POSIX clock for buffered samples and
events timestamping.
Following clocks, as listed in clock_gettime(2), are supported:
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and
CLOCK_TAI.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Acked-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We want the fixes in here, and we can resolve a merge issue in
drivers/iio/industrialio-trigger.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This fixes odd behavior after reboot.
The fact that we set the device to powerdown mode is not sufficient to
prevent DRDY being active because we might still have an unread sample.
Even if powerdown was sufficient keeping DRDY disabled while trigger is
not active is a good idea.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
("iio: st_sensors: verify interrupt event to status") caused
a regression when reading ST sensors from a HRTimer trigger
rather than the intrinsic interrupts: the HRTimer may
trigger faster than the sensor provides new values, and
as the check against new values available as a cause of
the interrupt trigger was done in the poll function,
this would bail out of the HRTimer interrupt with
IRQ_NONE.
So clearly we need to only check the new values available
from the proper interrupt handler and not from the poll
function, which should rather just read the raw values
from the registers, put them into the buffer and be happy.
To achieve this: switch the ST Sensors over to using a true
threaded interrupt handler.
In the interrupt thread, check if new values are available,
else yield to the (potential) next device on the same
interrupt line to check the registers. If the interrupt
was ours, proceed to poll the values.
Instead of relying on iio_trigger_generic_data_rdy_poll() as
a top half to wake up the thread that polls the sensor for
new data, have the thread call iio_trigger_poll_chained()
after determining that is is the proper source of the
interrupt. This is modelled on drivers/iio/accel/mma8452.c
which is already using a properly threaded interrupt handler.
In order to get the same precision in timestamps as
previously, where samples would be timestamped in the
poll function pf->timestamp when calling
iio_trigger_generic_data_rdy_poll() we introduce a
local timestamp in the sensor data, set it in the top half
(fastpath) of the interrupt handler and provide that to the
core when calling iio_push_to_buffers_with_timestamp().
Additionally: if the active scanmask is not set for the
sensor no IRQs should be enabled and we need to bail out
with IRQ_NONE. This can happen if spurious IRQs fire when
installing the threaded interrupt handler.
Tested with hard interrupt triggers on LIS331DL, then also
tested with hrtimers on the same sensor by creating a 75Hz
HRTimer and using it to poll the sensor.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Jonathan Cameron <jic23@kernel.org>
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Ensure failure to enable power regulators is properly handled.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Use SMBus "block read" protocol only when supported by adapter.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Remove st_sensors_get_buffer_element symbol export since not explicitly
used outside of st_sensors driver.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.
If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).
Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Acked-by: Rob Herring <rob@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This makes all ST sensor drivers check that they actually have
new data available for the requested channel(s) before claiming
an IRQ, by reading the status register (which is conveniently
the same for all ST sensors) and check that the channel has new
data before proceeding to read it and fill the buffer.
This way sensors can share an interrupt line: it can be flaged
as shared and then the sensor that did not fire will return
NO_IRQ, and the sensor that fired will handle the IRQ and
return IRQ_HANDLED.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The current buffer read code tries to optimize reads from the
sensor data registers by issuing a single read operation across
all the indata registers.
This doesn't work: when the LIS331DL accelerometer sensor is
configured to open drain, active low interrupt mode, this will
just clear the XDA (X-axis data available) bit in the STATUS_REG
register (0x27), while YDA, ZDA and even ZYXDA remain set to 1,
and the internal logic of the sensor holds the DRDY (INT1) line
asserted (the value of the status register is 0xee).
If we instead issue one read operation per enabled channel
(X, Y, Z) things start working and we can use open drain and
active low interrupts.
Note that a backported patch fixing this issue will be heading
via the fixes branch but changes in this file already in staging-next
will make that patch 'look' rather different. The code in here
is the correct one when that clash hits.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This fixes the error reported by checkpatch.pl:
ERROR: code indent should use tabs where possible
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This fixes the error reported by checkpatch.pl:
ERROR: code indent should use tabs where possible
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The driver goes to some length to dynamically allocate an array
to hold the channel addresses. However no ST sensor has more than
three channels (x, y, z at most). Instead of kmalloc():ing and
kfree():in the address array, just use a fixed array of three
elements.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Most ST MEMS Sensors that support interrupts can also handle sending
an active low interrupt, i.e. going from high to low on data ready
(or other interrupt) and thus triggering on a falling edge to the
interrupt controller.
Set up logic to inspect the interrupt line we get for a sensor: if
it is triggering on rising edge, leave everything alone, but if it
triggers on falling edges, set up active low, and if unsupported
configurations appear: warn with errors and reconfigure the interrupt
to a rising edge, which all interrupt generating sensors support.
Create a local header for st_sensors_core.h to share functions
between the sensor core and the trigger setup code.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Definition of ST_SENSORS_WAI_ADDRESS was introduced within a very
first commit of this driver, but it was never used.
This address is already defined as ST_SENSORS_DEFAULT_WAI_ADDRESS
in include/linux/iio/common/st_sensors.h
To avoid duplication of the same constant in two different places
called almost exactly the same, the one which was never used
should be removed.
Signed-off-by: Robert Kmiec <robert.r.kmiec@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"Quite a lot of activity in SPI this cycle, almost all of it in drivers
with a few minor improvements and tweaks in the core.
- Updates to pxa2xx to support Intel Broxton and multiple chip selects.
- Support for big endian in the bcm63xx driver.
- Multiple slave support for the mt8173
- New driver for the auxiliary SPI controller in bcm2835 SoCs.
- Support for Layerscale SoCs in the Freescale DSPI driver"
* tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits)
spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI
spi: pxa2xx: Add support for Intel Broxton
spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals
spi: pxa2xx: Add output control for multiple Intel LPSS chip selects
spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific
spi: Add DSPI support for layerscape family
spi: ti-qspi: improve ->remove() callback
spi/spi-xilinx: Fix race condition on last word read
spi: Drop owner assignment from spi_drivers
spi: Add THIS_MODULE to spi_driver in SPI core
spi: Setup the master controller driver before setting the chipselect
spi: dw: replace magic constant by DW_SPI_DR
spi: mediatek: mt8173 spi multiple devices support
spi: mediatek: handle controller_data in mtk_spi_setup
spi: mediatek: remove mtk_spi_config
spi: mediatek: Update document devicetree bindings to support multiple devices
spi: fix kernel-doc warnings about missing return desc in spi.c
spi: fix kernel-doc warnings about missing return desc in spi.h
spi: pxa2xx: Align a few defines
spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select
...
|
|
An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch changes various types to the appropriate endian specific
versions. Also introduces an additional local variable to avoid
a single variable being used for both be and cpu endianness.
These aren't bugs as such, but clearing them up does make the code
clearer.
Warning was:
sparse warnings: (new ones prefixed by >>)
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: sparse: incorrect type in assignment (different base types)
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: got restricted __be16 [usertype] <noident>
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
>> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: sparse: incorrect type in assignment (different base types)
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: got restricted __be16 [usertype] <noident>
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Measurement specialties drivers common part.
These functions are used by further drivers
in the patchset: TSYS01, TSYS02D, HTU21, MS5637, MS8607
Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This adds a debugfs hook to read/write registers in the ST
sensors using debugfs. Proved to be awesome help when trying
to debug why IRQs do not arrive.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of new device support, features and cleanup for the 4.3 cycle.
Take 2 also includes a fix set that was too late for the 4.2 cycle.
As we had a lot of tools and docs work in this set, I have broken those
out into their own categories in this description.
Fixes from the pull request '4th set of IIO fixes for the 4.2 cycle'.
* Poll functions for both event chardev and the buffer one were returning
negative error codes (via a positive value).
* A recent change to lsiio adding some error handling that was wrong and
stopped the tool working.
* bmg160 was missing some dependencies in Kconfig
* berlin2-adc had a misshandled register (wrote a value rather than a bitmap)
New device support
* TI opt3001 light sensor
* TXC PA12 ALS and proximity sensor.
* mcp3301 ADC support (in mcp320x driver)
* ST lsm303agr accelerometer and magnetometer drivers (plus some st-sensors
common support to allow different WHOAMI register addresses, devices with
fixed scale and allow interrupt equiped magnetometers).
* ADIS16305, ADIS16367, ADIS16445IMUs (in the adis16400 driver)
* ADIS16266 gyro (in the adis16260 driver)
* ADIS16137 gyro (in the adis16136 driver)
New functionality
* mmc35240 DT bindings.
* Inverse unit conversion macros to aid handing of values written to sysfs
attributes.
Core cleanup
* Forward declaration of struct iio_trigger to avoid a compile warning.
Driver cleanup / fixes
* mxs-lradc
- Clarify which parts are supported.
- Fix spelling erorrs.
- Missing/extra includes
- reorder includes
- add datasheet name listings for all usable channels (to allow them
to be bound by name from consumer drivers)
* acpi-als - add some function prefixes as per general iio style.
* bmc150_magn - replace a magic value with the existing define.
* vf610 - determine possible sample frequencies taking into account the
electrical characteristics (defining a minimum sample time)
* dht11
- whitespace
- additional docs
- avoid mulitple assignments in one line
- Use the new funciton ktime_get_resolution_ns to cleanup a nasty trick
previously used for timing.
* Fix all drivers that consider 0 a valid IRQ for historical reasons.
* Export I2C module alias info where previously missing (to allow autoprobing)
* Export OF module alias info where previously missing.
* mmc35240 - switch some variables into arrays to improve readability.
* mlx90614 - define some magic numbers for readability.
* bmc150_magn
- expand area locked by a mutex to cover all the use of the
data->buffer.
- use descriptive naming for a mask instead of a magic value.
* berin2-adc
- pass up an error code rather that a generic error
- constify the iio_chan_spec
- some other little tidy ups.
* stk8312
- fix a dependency on triggered buffers in kconfig
- add a check for invalid attribute values
- improve error handling by returning error codes where possible and
return immediately where relevant
- rework macro defs to use GENMASK etc
- change some variable types to reduce unnecessary casting
- clean up code style
- drop a local buffer copy for bulk reads and use the one in data->buffer
instead.
* adis16400 - the adis16448 gyroscope scale was wrong.
* adis16480 - some more wrong scales for various parts.
* adis16300 - has an undocumented product id and serial number registers so
use them.
* iio_simple_dummy - fix some wrong code indentation.
* bmc150-accel - use the chip ID to detect the chip present rather than
verifying the expected part was there. This was in response to a wrong
ACPI entry on the WinBook TW100.
* mma8452
- fix _get_hp_filter_index
- drop a double include
- pass up an error code rather than rewriting it
- range check input values to attribute writes
- register defs tidy up using GENMASK and reordering them to be easier to
follow.
- various coding style cleanups
- put the Kconfig entry in the write place (alphabetically).
Tools related
* Tools cleanup - drop an explicity NULL comparison, some unnecessary braces,
use the ARRAY_SIZE macro, send error messages to stderr instead of dropping
them in the middle of normal output.
* Fix tools to allow that scale and offset attributes are optional.
* More tools fixes including allowing true 32bit data (previously an overflow
prevented more than 31bits)
* Drop a stray header guard that ended up in a c file.
* Make calc_digits static as it isn't exported or in the header.
* Set ci_array pointer to NULL after free as a protection against non safe
usage of the tools core code. Also convert a double pointer to a single
one as the extra level of indirection was unnecessary.
Docs
* DocBook introduction by Daniel Baluta. Glad we are beginning to
draw together some more introductory docs to suplement the various
tools / examples.
* Drop bytes_per_datum sysfs attribute docs as it no longer exists.
* A whole load of missing / fixing of kernel-doc for the core of IIO.
* Document the trigger name sysfs attribute in the ABI docs.
* Minor typos in the ABI docs related to power down modes.
|
|
Some sensors could have only one full scale value. This means that the
sensor hasn't a full scale register. This commit add a check on the
configured full scale address to support such kind of sensors.
Signed-off-by: Giuseppe Barba <giuseppe.barba@st.com>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This patch permits to configure the WhoAmI register address
because some device could have not a standard address for
this register.
Signed-off-by: Giuseppe Barba <giuseppe.barba@st.com>
Reviewed-by: Denis Ciocca <denis.ciocca@st.com>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We need the staging fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First set of IIO fixes for the 4.2 cycle.
* Fix a regression in hid sensors suspend time as a result of adding runtime
pm. The normal flow of waking up devices in order to go into suspend
(given the devices are normally suspended when not reading) to a regression
in suspend time on some laptops (reports of an additional 8 seconds).
Fix this by checking to see if a user action resulting in the wake up, and
make it a null operation if it didn't. Note that for hid sensors, there is
nothing useful to be done when moving into a full suspend from a runtime
suspend so they might as well be left alone.
* rochip_saradc: fix some missing MODULE_* data including the licence so that
the driver does not taint the kernel incorrectly and can build as a module.
* twl4030 - mark irq as oneshot as it always should have been.
* inv-mpu - write formats for attributes not specified, leading to miss
interpretation of the gyro scale channel when written.
* Proximity ABI clarification. This had snuck through as a mess. Some
drivers thought proximity went in one direction, some the other. We went
with the most common option, documented it and fixed up the drivers going
the other way. Fix for sx9500 included in this set.
* ad624r - fix a wrong shift in the output data.
* at91_adc - remove a false limit on the value of the STARTUP register
applied by too small a type for the device tree parameter.
* cm3323 - clear the bits when setting the integration time (otherwise
we can only ever set more bits in the relevant field).
* bmc150-accel - multiple triggers are registered, but on error were not being
unwound in the opposite order leading to removal of triggers that had not
yet successfully been registered (count down instead of up when unwinding).
* tcs3414 - ensure right part of val / val2 pair read so that the integration
time is not always 0.
* cc10001_adc - bug in kconfig dependency. Use of OR when AND was intended.
|
|
In ancient times it was necessary to manually initialize the bus
field of an spi_driver to spi_bus_type. These days this is done in
spi_register_driver(), so we can drop the manual assignment.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
To: Karol Wrona <k.wrona@samsung.com>
To: linux-iio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Karol Wrona <k.wrona@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Third round of new IIO drivers, cleanups and functionality for the 4.2 cycle.
Given Linus announced a 4.8rc coming up, hopefully time for one more
lot of IIO patches this cycle. Some of these are actually
improvements / fixes for patches earlier in the cycle.
New device support
* st_accel driver - support devices with 8 bit channels.
Cleanup
* A general cleanup of the iio tools under /tools/ from Hartmut.
I'm more than a little embarassed by how bad some of these were! Are well,
much more refined and less bug prone now.
These cover lots of stuff like unhandled error returns, memory leaks as
well as general refactoring to tidy the code up.
* iio_simple_dummy - fix memory leaks in the init functions, drop some
pointless error returns from functions that never generate errors and
make the module parameter explicitly unsigned.
* More buffer handling reworks from Lars-Peter, this time targetting hardware
buffers (a little used corner that looks likely to get more use in the near
future). Specifically:
- Always compute the masklength as inkernel buffer users may need it.
- Add a means of labeling which buffer modes a given buffer implementation
supports.
- In the case of hardware buffers, require strict scan matching rather than
matching to a superset. Currently the demux is bypassed by these drivers
(this may well not change for efficiency reasons) so allowing a superset
of channels to be selected would otherwise lead to more data than requested
confusing userspace.
Driver funcationality improvments
* mmc35240 - adds a compensation to the raw values as borrowed form Memsic's
own input driver.
* mma8452
- event support
- event debouncing
- high pass filter configuration
- triggers
* vf610 - allow conversion mode to be adjusted
Fixlets
* mmc35240
- Off by one error that by coincidence had no real effect.
- i2c_device_name should be lowercase.
- Lack of null terminator at end of attributes array.
- Avoid computing the fractional part of the magnetic field by moving
the scaling into userspace where floating point is available to simplify
the maths.
- Use a smaller sleep before assuming the measurement is done. This is
safe and improves the possible polling rate.
- Fix sensitivity on z-axis - datasheet disagrees with Memsic's releasedd
code and the value used in the code seems to be correct.
* stk3310 - make a local variable signed to ensure error handling works.
* twl4030
- fix calculation of the temperature sense current - bug unlikely
to have ever been noticed as the difference is small.
- Fix errors in descriptions.
|
|
Some sensors like the LIS331DL only support 8bit data by a single
register per axis. These utilize the MSB byte. Make it possible
to register these apropriately.
A oneliner change is needed in the ST sensors core to handle 8bit
reads as this is the first supported 8bit sensor.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
By default all the sensors are runtime suspended state (lowest power
state). During Linux suspend process, all the run time suspended
devices are resumed and then suspended. This caused all sensors to
power up and introduced delay in suspend time, when we introduced
runtime PM for HID sensors. The opposite process happens during resume
process.
To fix this, we do powerup process of the sensors only when the request
is issued from user (raw or tiggerred). In this way when runtime,
resume calls for powerup it will simply return as this will not match
user requested state.
Note this is a regression fix as the increase in suspend / resume
times can be substantial (report of 8 seconds on Len's laptop!)
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Len Brown <len.brown@intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We want the fixes in here for testing and merge issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
The usual mixed bag of fixes for IIO in the 4.1 cycle.
Second version of this pull request as a small fix to a fix turned
up before Greg pulled it for a cc10001 patch near the top of the tree.
One core fix
* Set updated for a iio kfifo was incorrectly set to false during a failed
update, resulting in atttempts to repeat the failed operation appearing
to succeed.
This time I've decided to list the driver fixes in alphabetical order rather
than 'randomly'.
* axp288_adc - a recent change added a check for valid info masks when
reading channels from consumer drivers.
* bmp280 - temperature compensation was failing to read the tfine value, hence
causing a temperature of 0 to always be returned and incorrect presure
measurements.
* cc10001 - Fix channel number mapping when some channels are reserved for
remote CPUs. Fix an issue with the use of the power-up/power-down register
(basically wrong polarity). Fix an issue due to the missinterpretting the
return value from regulator_get_voltage. Add a delay before the start bit
as recommended for the hardware to avoid data corruption.
* hid pressure - fix channel spec of modfiied, but no modifier (which makes no
sense!)
* hid proximity - fix channel spec of modified, but no modifier (which makes
no sense!). Fix a memory leak in the probe function.
* mcp320x - occasional incorrect readings on dma using spi busses due to
cacheline corruption. Fixed by forcing ___cacheline_aligned for the buffers.
* mma9551 - buffer overrun fix (miss specified maximum length of buffers)
* mma9553 - endian fix on status message. Add an enable element for activity
channel. Input checking for activity period to avoid rather unpredictable
results.
* spmi-vadc - fix an overflow in the output value normalization seen on some
boards.
* st-snesors - oops due to use of a mutex that is not yet initialized during
probe.
* xilinx adc - Some wrong register addresses, a wrong address for vccaux
channel, incorrect scale on VREFP and incorrect sign on VREFN.
|
