user/sven/linux.git/include/linux/hid-sensor-hub.h, branch v5.10.204

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 335

2019-06-05T15:37:06Z

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 51 franklin st fifth floor boston ma 02110 1301 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 111 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Alexios Zavras Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.567572064@linutronix.de Signed-off-by: Greg Kroah-Hartman

iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers

2018-11-16T11:42:12Z

Before this commit sensor_hub_input_attr_get_raw_value() failed to take the signedness of 16 and 8 bit values into account, returning e.g. 65436 instead of -100 for the z-axis reading of an accelerometer. This commit adds a new is_signed parameter to the function and makes all callers pass the appropriate value for this. While at it, this commit also fixes up some neighboring lines where statements were needlessly split over 2 lines to improve readability. Signed-off-by: Hans de Goede Acked-by: Srinivas Pandruvada Acked-by: Benjamin Tissoires Cc: Signed-off-by: Jonathan Cameron

iio: hid-sensor-trigger: Don't touch sensors unless user space requests

2017-10-14T18:29:50Z

One of the user complained that on his system Thinkpad Yoga S1, with commit f1664eaacec3 ("iio: hid-sensor-trigger: Fix the race with user space powering up sensors") causes the system to resume immediately on suspend (S3 operation). On this system the sensor hub is on USB and is a wake up device from S3. So if any sensor sends data on motion, the system will wake up. This can be a legitimate use case to wake up device motion, but that needs proper user space support to set right thresholds. In fact the above commit didn't cause this regression, but any operation which cause sensors to wake up would have caused the same issue. So if user reads the raw sensor data, same issue occurs, with or without this commit. Only difference is that the above commit by default will trigger a power up and power down of sensors as part of runtime pm enable (runtime enable will cause a runtime resume callback followed by runtime_suspend callback). Previously user has to do some action on sensors. On investigation it was observed that the current driver correctly changing the state of all sensors to power off but then also some sensor will still send some data. Only option is to never power up any sensor. Only good option is to: - Using sysfs interface disable USB as a wakeup device (This will not need any driver change) Since some user don't care about sensors. So for those users this change brings back old functionality. As long as they don't cause any operation to power up sensors (like raw read or start iio-sensor-proxy service), the sensors will not be to touched. This is done by delaying run time enable till user space does some operation with sensors. Link: https://bugzilla.kernel.org/show_bug.cgi?id=196853 Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

iio: hid-sensor-hub: Implement batch mode

2017-05-16T18:44:01Z

HID sensor hubs using Integrated Senor Hub (ISH) has added capability to support batch mode. This allows host processor to go to sleep for extended duration, while the sensor hub is storing samples in its internal buffers. 'Commit f4f4673b7535 ("iio: add support for hardware fifo")' implements feature in IIO core to implement such feature. This feature is used in bmc150-accel-core.c to implement batch mode. This implementation allows software device buffer watermark to be used as a hint to adjust hardware FIFO. But HID sensor hubs don't allow to change internal buffer size of FIFOs. Instead an additional usage id to set "maximum report latency" is defined. This allows host to go to sleep upto this latency period without getting any report. Since there is no ABI to set this latency, a new attribute "hwfifo_timeout" is added so that user mode can specify a latency. This change checks presence of usage id to get/set maximum report latency and if present, it will expose hwfifo_timeout. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

iio: hid-sensor: Store restore poll and hysteresis on S3

2017-04-08T14:13:36Z

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 Tested-by: Ritesh Raj Sarraf Tested-by: Song, Hongyan Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

iio: accel: hid-sensor-accel-3d: Add timestamp

2016-12-03T10:06:13Z

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 Signed-off-by: Jonathan Cameron

iio: hid-sensors: use asynchronous resume

2016-08-21T19:12:32Z

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 Signed-off-by: Jonathan Cameron

Merge tag 'iio-fixes-for-4.2a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

2015-07-13T21:18:07Z

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.

hid-sensor: Fix suspend/resume delay

2015-06-02T21:15:26Z

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 Tested-by: Len Brown Cc: Signed-off-by: Jonathan Cameron

HID: hid-sensor-hub: Fix debug lock warning

2015-05-12T12:13:20Z

When CONFIG_DEBUG_LOCK_ALLOC is defined, mutex magic is compared and warned for (l->magic != l), here l is the address of mutex pointer. In hid-sensor-hub as part of hsdev creation, a per hsdev mutex is initialized during MFD cell creation. This hsdev, which contains, mutex is part of platform data for the a cell. But platform_data is copied in platform_device_add_data() in platform.c. This copy will copy the whole hsdev structure including mutex. But once copied the magic will no longer match. So when client driver call sensor_hub_input_attr_get_raw_value, this will trigger mutex warning. So to avoid this allocate mutex dynamically. This will be same even after copy. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina