| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Fifth set of IIO fixes for the 4.11 cycle.
As these are rather late in the cycle, they may sneak over into 4.12.
There is a fix for a regression caused by another fix (hid sensors
hardware seems to vary a lot in how various corner cases are handled).
* ad7303
- fix channel description. Numeric values were being passed as characters
presumably leading to garbage from the userspace interface.
* as3935
- the write data macro was wrong so fix it.
* bmp280
- incorrect handling of negative values as being unsigned broke humidity
calculation.
* hid-sensor
- Restore the poll and hysteresis values after resume as some hardware
doesn't do it.
* stm32-trigger
- buglet in reading the sampling frequency
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Fourth set of IIO new device support, features and cleanups for the 4.12 cycle
New device support
* max1117, 1118 and 1119
- new ADC driver
* max9611
- new ADC driver
* pm8xxx hk/xoadc
- new driver with some shared features broken out from the SPMI vadc.
* sun4i-gpadc
- A33 thermal sensor support (with associated rework)
* stm32-dac
- new driver and bindings
* stm32 trigger
- enable support of quadrature encoder device and counter modes
Features
* apds9960
- use the runtime pm for normal suspend
* stm32-adc
- add opition to sest resolution via devicetree
* xoadc
- augment DT bindings to deal with some weird mux cases
Cleanups
* ad5933
- protect direct mode using claim and release helpers
* ade7759
- S_IRUGO and friends to octal in two goes
* adis16203
- drop unnecessary brackets
* hid-sensor
- fix unbalanced pm_runtieme_enable error when probing after remove
* lsm6dsx
- use actual part numbers for device name when known
- simplify data read pin parsing
* mpu3050
- avoid double reporting errors
|
|
We want the staging and iio fixes in here to handle merging easier.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When a hid sensor module is removed and modprobed again we see
error for unbalanced pm_runtime. This issue is caused by not
deactivating runtime PM on removal. So on modprobe again when
activated again, this will print this error.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
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>
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Third set of new device support, cleanups and features for IIO in the 4.12 cycle
Somewhat dominated in patch numbers of last of the outreachy application
window related patches (they are still coming, despite window being closed
which is good to see!)
Good set of new drivers as well.
New device support
* ASPEED ADC
- new driver
* cpcap PMIC ADC
- new driver
* hid-humidity
- driver for HID compatible humidity sensors.
* ltc2497 ADC
- new driver
* mpu6050
- bring bindings up to date and add trivial support for 9250
* rockchip-saradc
- update bindings to cover rk3328
* vl6180 light, proximity and time of flight sensor.
- new driver
Features
* meson-saradc
- add calibration
Cleanup and minor fixes
* ad5504
- constify attribute_group structure
- drop casting of void *
* ad7150
- replace some shifts of 1 by BIT macro usage
* ad7152
- blank lines between function definitions
* ad7280a
- octal permissions.
* ad7606
- replace use of core mlock mutex with a local lock
* ad7746
- replace some shifts of 1 by BIT macro usage
- function parameter alignment
- drop some excessive brackets (introduced in last pull request)
* ad7753
- white space cleanup
* ad7754
- includes in alphabetical order and groupped appropriately.
- change from missuse of internal mlock mutex to using the buffer lock to
also protect values during frequency update.
* ad779x
- constify attribute_group structures
* ad9832
- octal permissions
* adis16060
- remove use of core mlock mutex in favour of adding a local
_spi_write_then_read which can use the local buffer protection lock.
- fix naming of above function.
* adis16203
- remove locking during reads of calibbias that doesn't protect anything
not protected elsewhere.
* adis16209
- remove unnecessary braces in single statement if
* adis16240
- remove unnecessary braces in single statement if
* adt7136
- drop excess blank lines and put some in between functions.
* ams-iaq
- replace comma with semi colon. Not actual bug, just unusual syntax.
* apds9960
- constify attribute group structure
* as3935
- constify attribute group structure
* bm1750
- constify attribute group structure
* cros_ec
- devm version of triggered buffer setup to simplify code.
* exynos
- drop casting of void *
* hdc100x
- constify attribute_group structure
* hid-accel
- fix wrong scale for newly introduced gravity sensor.
* hts221
- drop casting of void *
* hx711
- constify attribute_group structure
* imx7d_adc
- drop casting of void *
* lm35333
- constify attribute_group structure
* lsm6dsx
- drop casting of void *
- hold ODR configuration until enabling to avoid a race condition.
* max1027
- drop casting of void *
* max11100
- fix a comma where semicolon was intended (no actual bug, just odd)
* max1363
- constify attribute_group structure
* ms sensors
- drop casting of void *
* rockchip_saradc
- drop casting of void *
* sun4i-gpadc
- fix missing dependency on THERMAL or presence of stubs (issue only
introduced in pervious set)
- drop casting of void *
* tsl2x7x
- fix wrong standard deviation calc. Note these aren't actually used for
anything at the moment so bug didn't really matter.
- constify attribute group structure.
* vf610adc
- drop casting of void *
* vz89x
- replace comma with semicolon. Not actual bug, just odd syntax.
* zpa2326
- drop casting of void *
|
|
When system bootup without get sensor property, set sensor
property will be fail.
If no get_feature operation done before set_feature, the sensor
properties will all be the initialized value, which is not the
same with sensor real properties. When set sensor property it will
write back to sensor the changed perperty data combines with other
sensor properties data, it is not right and may be dangerous.
In order to get all sensor properties, choose to read one of the sensor
properties(no matter read any sensor peroperty, driver will get all
the peroperties and return the requested one).
Fixes: 73c6768b710a ("iio: hid-sensors: Common attribute and trigger")
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>
|
|
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal <singhalsimran0@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
We need the IIO fixes in here as well to handle merge issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Environmental humidity sensor is a hid defined sensor,
it shows raw humidity measurement of air.
More information can be found in:
http://www.usb.org/developers/hidpage/HUTRR39b.pdf
According to IIO ABI definition, humidityrelative data output unit is
milli percent. Add the unit convert from percent to milli percent.
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Scale value include two parts: unit conversion and exponent conversion.
Add gravity unit convert table to fix gravity sensor scale value not
right issue.
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>
|
|
Use resourced managed function devm_iio_triggered_buffer_setup
to make error path simpler and be able to get rid of the remove
function.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The cros_ec_sensors_read function must return the type of value on all
cases. This was always true except for RAW and CALIBBIAS data which
returned an error or 0. This patch just fixes the mistake I introduced
when submitting the series.
Fixes: commit c14dca07a31d (iio: cros_ec_sensors: add ChromeOS EC
Contiguous Sensors driver)
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
sensor properties losing after resume from S3
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>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Environmental temperature sensor is a hid defined sensor,
it measures temperature.
More information can be found in:
http://www.usb.org/developers/hidpage/HUTRR39b.pdf
According to IIO ABI definition, IIO_TEMP data output unit is
milli degrees Celsius. Add the unit convert from degree to milli degree.
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>
|
|
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
|
|
As a precursor to splitting buffer.h, lets make sure all drivers
include the relevant headers rather than relying on picking them
up from kfifo_buf.h.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
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>
|
|
Added timestamp channel. With this change, each sample has a timestamp.
This timestamp can be from the sensor hub when present or local kernel
timestamp. HID sensors can send timestamp with input data using usage id
HID_USAGE_SENSOR_TIME_TIMESTAMP. This timestamp value is converted to
nano seconds before pushing this sample to the iio core.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Third set of IIO new device support, features and cleanup for the 4.10 cycle.
Includes Peter Rosin's interesting drivers for a comparator. First complex
use we have had with an analog front end made from discrete components.
Brian Masney's work on moving the tsl2583 driver out of staging also
feature extensively!
New Drivers
* DAC based on a digital potentiometer
- New driver for the use of a dpot as a DAC. Includes bindings and Axentia
entry in vendor prefixes.
* Envelope detector baed on DAC and a comparator including device tree
bindings.
Staging Graduation
* tsl2583.
Core new features
- Core provision for _available attributes. This one had been stalled for
a long time until Peter picked it up and ran with it!
- In kernel interface helpers to retrieve available info from channels.
Driver new features
* mcp4531
- Add range of available raw values (used for the dpot dac driver).
Driver cleanups and fixes for issues introduced
* ad7766
- Testing the wrong variable following devm_regulator_bulk_get introduced
with the driver earlier in this cycle.
* ad9832
- Fix a wrong ordering in the probe introduced in the previous set of
patches. A use before allocation bug.
* cros_ec_sensors
- Testing for an error in a u8 will never work.
* mpu3050
- Remove duplicate initializer for the module owner.
- Add missing i2c dependency.
- Inform the i2c mux core how it is used - step one in implifying device
tree bindings.
* st-sensors
- Get rid of large number of uninformative defines in favour of putting the
constants where they are relevant. It is clear what they are from where
they are used.
* tsl2583
- Fix unused function warning when CONFIG_PM disabled and remove the
ifdefs in favour of __maybe_unused.
- Refactor taos_chip_on to only read relevant registers.
- Make sure calibscale and integration time are being set.
- Verify chip is in ready to be used before calibration.
- Remove some repeated checks for chip status (it's protected by a mutex
so can't change until it's released)
- Change current state storage from a tristate enum to a boolean seeing as
only two values are actually used now.
- Drop a redundant write to the control regiser in taos_probe (it's a noop)
- Drop the FSF mailing address.
- Clean up logging to not use hard coded function names (use __func__
instead).
- Cleanup up variable and function name prefixes.
- Alignment of #define fixes.
- Fix comparison between signed and unsigned integer warnings.
- Add some newlines in favour of readability.
- Combine the two sysfs ABI docs that somehow ended up in different places.
- Fix multiline comment syntax.
- Move a code block to inside an else statement as it makes more sense there.
- Change tsl2583_als_calibrate to return 0 rather than a value nothing
reads.
- Drop some pointless brackets
- Don't assume 32bit unsigned int.
- Change to a per device instance lux table.
- Add missing tsl2583 to the list of supported devices in the intro comments.
- Improve commment on clearing of interrupts.
- Drop some uninformative comments.
- Drop a memset call that doesn't do anything useful any more.
- Don't initialize some return variables that are always set.
- Add Brian Masney as a module author after all these changes.
|
|
We want the staging/iio fixes in here as well to resolve issues and
merge problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
status is a u8 hence the check if status is less than zero has no effect.
Fix this by replacing status with int ret so the less than zero compare
will correctly detect errors.
Issue found with static analysis with CoverityScan, CID 1375919
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Fixes: 974e6f02e27e ("iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub")
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.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>
|
|
legitimacy
Neither sample frequency value nor hysteresis value can be set to be a
negative number, check and return "Invalid argument" if they are negative.
If not do this change, sample_frequency will be set into some unknown
value, read hysteresis value after write negative number will return
"Invalid argument".
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>
|
|
Would have merged this into the original patch as a fixup but I've already
pushed that out as an immutable branch for others to use so it'll have
to be a separate patch. The original select had a typo as well.
Trying to do this via a select was opening a can of worms due to
a tree of other elements that would also have needed selecting.
A simple depends seems much mroe straight forward and appropriate in this
case.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
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>
|
|
Check whether the ChromeOS Embedded Controller is a sensor hub and in
such case issue a command to get the number of sensors and register them
all.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Handle 3d contiguous sensors like Accelerometers, Gyroscope and
Magnetometer that are presented by the ChromeOS EC Sensor hub.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Add the core functions to be able to support the sensors attached behind
the ChromeOS Embedded Controller and used by other IIO cros-ec sensor
drivers.
The cros_ec_sensor_core driver matches with current driver in ChromeOS
4.4 tree, so it includes all the fixes at the moment. The support for
this driver was made by Gwendal Grignou. The original patch and all the
fixes has been squashed and rebased on top of mainline.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
[eballetbo: split, squash and rebase on top of mainline the patches
found in ChromeOS tree]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.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 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>
|
