| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of new device support, features and cleanups for IIO in the 4.11 cycle.
It's shaping to be another fairly busy cycle. Lots more on the way!
New device support
* ads7950
- new driver supporting ads7950, ads7951, ads7952, ads7953, ads7954,
ads7955, ads7956, ads7957, ads7958, ads7959, ads7960, and ads7961 ADCs.
* cm3605
- New driver for this light sensor and proximity sensor which is an
analog part with some additional digital controls.
* hx711
- New driver.
Core new stuff
* Gravity sensor type. This is a processed datastream in which the device
will try to work out which way is down.
* Split the buffer.h file into two parts. One provides the interface to 'use'
a buffer, the second provides the internals of the buffer functionality as
needed by implementations of buffers.
- Move documentation inline so as to allow use of private: tag when
generating documentation.
- Add some utility functions for the few things that are directly done
with the buffers.
- Stop exporting functions that no-one uses outside of the core code.
- Push docs down by the code in the c file where they should have always
been.
- Fix typo in kernel-doc for buffer.
- push down some includes that were previously happening implicitly.
- stop enabling the timestamp of the dummy device.
Features and cleanups
* ad5592r
- ACPI support
* ad5593r
-ACPI support.
* ad5933
- Fix a false comment about size of a particular register.
* ad7150
- replace S_IRUGO | S_IWUSR with 0644. I'm not that keen on these patches
in general, but as it was nicely presented I took this one anyway. As a
general rule will only take these as part of a larger driver cleanup.
- don't eat an error but rather reutnr it in the write_event_config callback.
* ad7606
- replace non standard range attibute with _scale
* ade7753
- use usleep_range for short sleeps
* ade7754
- use usleep_range for short sleeps
* ade7758
- use usleep_range for short sleeps
* ade7759
- use usleep_range for short sleeps
* ade7854
- use usleep_range for short sleeps
* adis16201
- fix description
* adis16203
- fix description
- fix copyright year
* adis16209
- fix description
* adt7316
- Add braces to arms of if else statement (for consistency)
- Alignment fixes.
* axp288
- Fix up an issue with accidental overwrites of data.
* bmi160
- add deivce tables for i2c and spi to support correctly identifying the
full dt name (including manufacturer).
- device tree binding.
* bmp280
- use usleep_range for short sleeps.
* cm3232
- return error from cm3232_reg_init rather than eating it if the last write
fails.
* dummy driver
- remove a semicolor found at end of a function defintition.
* exynos-adc
- use usleep_range for short sleeps.
* hid-sensor (accel)
- Add timestamp support. The hardware can provide timestamps so lets support
them. If not fall back to timestamps estimated in kernel.
* hid-sensor (light)
- Add a duplicate ID for the light channels so as to keep existing interface
whilst also using the more standard IIO interface.
* hts221
- acpi probing
* imx25-gcq
- Add a macro call to allow this driver to be automatically loaded.
* isl29028
- reorganise code to avoid deep nesting of if statements.
- move chip test and default regs into a function suitable or sharing with
power management code.
- tidy up some code alignment.
* lidar-lite-v3
- introduce compatible strings that make it clear Garmin have consideral
friends.
* mma8452
- avoid returning signed value when unsigned is appropriate
* spmi-vadc
- Update function for generic voltage conversion to take into account that
different channels on this device should be handled differently.
- Rework code to allow per channel voltage scaling and support the standard
options for this hardware.
- Fixup three minor issues with the above patches for this part. These all
effect test builds rather than the native builds for the part, but good to
clean them up anyway.
* st_sensors
- support device matching from the ACPI DST tables.
- acpi based probing for accelerometers
- acpi based probing for pressure sensors
- Allow pressure sensors to read negative values.
- Export sampling frequency for lps25h and lps331ap.
- Add support for the old DT bindings from the period when these deivces
were often supported through windows.
Docs fixup:
* typo in sysfs-bus-iio
|
|
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>
|
|
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>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Add support to match st sensors using information passed from ACPI DST
tables.
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
We want the fixes in here for testing and merge issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The ST sensors are detected by reading a WhoAmI register and
matching the number found to a sensor name string. To make it
easier to figure out what happens when things go wrong, print
the WhoAmI value and the device name we're trying to match.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Not all sensors support BDU (block data update) and in fact a
bunch of the in-kernel sensor settings do not specify the
BDU address field. Make this optional.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Some sensors such as magnetometers and pressure sensors doesn't
have interrupts at all, and thus no DRDY setting applies. Make
the assignment of an interrupt optional, and do not call
st_sensors_set_drdy_int_pin() if there is no drdy (data ready)
pin specified.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Print a proper error message if we're missing the trigger
IRQ.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
In SPI mode the transfer buffer is locked with a mutex. However this
mutex is only initilized after the probe, but some transfer needs to
be done in the probe.
To fix this bug we move the mutex initialization at the beginning of
the device probe.
Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
sizeof(u8) is always 1.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of new drivers, features and cleanups for IIO in the 3.19 cycle.
New drivers / supported parts
* rockchip - rk3066-tsadc variant
* si7020 humidity and temperature sensor
* mcp320x - add mcp3001, mcp3002, mcp3004, mcp3008, mcp3201, mcp3202
* bmp280 pressure and temperature sensor
* Qualcomm SPMI PMIC current ADC driver
* Exynos_adc - support exynos7
New features
* vf610-adc - add temperature sensor support
* Documentation of current attributes, scaled pressure, offset and
scaled humidity, RGBC intensity gain factor and scale applied to
differential voltage channels.
* Bring iio_event_monitor up to date with newer modifiers.
* Add of_xlate function to allow for complex channel mappings from the
device tree.
* Add -g parameter to generic_buffer example to allow for devices with
directly fed (no trigger) buffers.
* Move exynos driver over to syscon for PMU register access.
Cleanups, fixes for new drivers
* lis3l02dq drop an unneeded else.
* st sensors - renam st_sensors to st_sensor_settings (for clarity)
* st sensors - drop an unused parameter from all the probe utility
functions.
* vf610 better error handling and tidy up.
* si7020 - cleanups following merge
* as3935 - drop some unnecessary semicolons.
* bmp280 - fix the pressure calculation.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First round of IIO fixes for the 3.18 cycle.
* ad5933 - fix a null pointer dereference due to an old change that prevents
different channels being registered for the buffer and used for sysfs
interfaces.
* ad5933 - Drop a bonus _raw from attribute names.
* st-sensors - Makes sure the correct number of elements are copied when
filling a local buffer copy.
* mxs-lradc - Disable clocks in a failure path during probe so they aren't
left running.
|
|
Use byte_for_channel as iterator to properly initialize the buffer.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: <Stable@vger.kernel.org>
|
|
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This patch change structure name and related variables names.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We want the fixes in there, and it resolves a merge issue with
drivers/iio/accel/bma180.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Value from st_sensors_set_drdy_int_pin() is assigned to err here,
but that stored value is not used before it is overwritten. To fix
this we're enforcing a check on st_sensors_set_drdy_int_pin()'s
return value and if it's an error, we're returning right away.
Cc: jic23@kernel.org
Cc: linux-iio@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This can result in wrong reference count for trigger device, call
iio_trigger_get to increment reference.
Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
with Jonathan.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
|
|
The I2C devices that make up the STMicroelectronics MEMS sensors
may be sneakily enabled by cleverly giving the device node the same
name as a string match from the platform device ID table. However
the right method is to use the compatible string.
On detection, the ST sensors use the ID string to probe and
instatiate the right sensor driver, so pass the kernel-internal ID
string in the .data field of the OF match table, and set the I2C
client name to this name when a compatible match is used.
This avoids having misc Linux-specific strings floating around in
the device tree.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Currently the STMicroelectronics sensors only support one single
platform data item: configuration of the DRDY (data ready) pin
for a particular design. Augment the core to prioritize and take
this information from the device tree if the parent device has an
assigned device node, else fall back to passed in platform data
(usually the default data).
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
support.
This allows in kernel client drivers to access this
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
|
|
Currently the pressure sensor has code to retrieve and enable two
regulators for Vdd and Vdd IO, but actually these voltage inputs
are found on all of these ST sensors, so move the regulator
handling to the core and make sure all the ST sensors call these
functions on probe() and remove() to enable/disable power.
Here also mover over to obtaining the regulator from the *parent*
device of the IIO device, as the IIO device is created on-the-fly
in this very subsystem it very unlikely evert have any regulators
attached to it whatsoever. It is much more likely that the parent
is a platform device, possibly instantiated from a device tree,
which in turn have Vdd and Vdd IO supplied assigned to it.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
