kernel/linux.git/include/linux/hid-sensor-hub.h, branch v6.6.132

iio: Add relative sensitivity support

2021-03-11T20:47:09+00:00

Some hid sensors may use relative sensitivity such as als sensor. This patch adds relative sensitivity checking for all hid sensors. Signed-off-by: Ye Xiang Acked-by: Jiri Kosina Link: https://lore.kernel.org/r/20210207070048.23935-2-xiang.ye@intel.com Signed-off-by: Jonathan Cameron

iio: hid-sensors: Move get sensitivity attribute to hid-sensor-common

2021-03-11T20:47:09+00:00

No functional change has been made with this patch. The main intent here is to reduce code repetition of getting sensitivity attribute. In the current implementation, sensor_hub_input_get_attribute_info() is called from multiple drivers to get attribute info for sensitivity field. Moving this to common place will avoid code repetition. Signed-off-by: Ye Xiang Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210201054921.18214-2-xiang.ye@intel.com Signed-off-by: Jonathan Cameron

HID: correct kernel-doc notation in

2021-01-26T13:24:26+00:00

Correct kernel-doc notation in HID header files (include/linux/hid*.h). Add notation (comments) where it is missing. Use the documented "Return:" notation for function return values. Fix a few typos/spellos. Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Signed-off-by: Jiri Kosina

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

2019-06-05T15:37:06+00:00

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:12+00:00

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:50+00:00

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:01+00:00

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:36+00:00

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:13+00:00

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:32+00:00

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