summaryrefslogtreecommitdiff
path: root/include/linux/hid-sensor-hub.h
AgeCommit message (Collapse)AuthorFilesLines
2017-10-14iio: hid-sensor-trigger: Don't touch sensors unless user space requestsSrinivas Pandruvada1-0/+1
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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-05-16iio: hid-sensor-hub: Implement batch modeSrinivas Pandruvada1-0/+5
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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-04-08iio: hid-sensor: Store restore poll and hysteresis on S3Srinivas Pandruvada1-0/+2
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>
2016-12-03iio: accel: hid-sensor-accel-3d: Add timestampSrinivas Pandruvada1-0/+4
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>
2016-08-21iio: hid-sensors: use asynchronous resumeSrinivas Pandruvada1-0/+1
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>
2015-07-14Merge tag 'iio-fixes-for-4.2a' of ↵Greg Kroah-Hartman1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of IIO fixes for the 4.2 cycle. * Fix a regression in hid sensors suspend time as a result of adding runtime pm. The normal flow of waking up devices in order to go into suspend (given the devices are normally suspended when not reading) to a regression in suspend time on some laptops (reports of an additional 8 seconds). Fix this by checking to see if a user action resulting in the wake up, and make it a null operation if it didn't. Note that for hid sensors, there is nothing useful to be done when moving into a full suspend from a runtime suspend so they might as well be left alone. * rochip_saradc: fix some missing MODULE_* data including the licence so that the driver does not taint the kernel incorrectly and can build as a module. * twl4030 - mark irq as oneshot as it always should have been. * inv-mpu - write formats for attributes not specified, leading to miss interpretation of the gyro scale channel when written. * Proximity ABI clarification. This had snuck through as a mess. Some drivers thought proximity went in one direction, some the other. We went with the most common option, documented it and fixed up the drivers going the other way. Fix for sx9500 included in this set. * ad624r - fix a wrong shift in the output data. * at91_adc - remove a false limit on the value of the STARTUP register applied by too small a type for the device tree parameter. * cm3323 - clear the bits when setting the integration time (otherwise we can only ever set more bits in the relevant field). * bmc150-accel - multiple triggers are registered, but on error were not being unwound in the opposite order leading to removal of triggers that had not yet successfully been registered (count down instead of up when unwinding). * tcs3414 - ensure right part of val / val2 pair read so that the integration time is not always 0. * cc10001_adc - bug in kconfig dependency. Use of OR when AND was intended.
2015-06-03hid-sensor: Fix suspend/resume delaySrinivas Pandruvada1-0/+1
By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Len Brown <len.brown@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-05-12HID: hid-sensor-hub: Fix debug lock warningSrinivas Pandruvada1-2/+2
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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-04-14Merge branch 'for-4.1/sensor-hub' into for-linusJiri Kosina1-10/+45
Conflicts: drivers/iio/common/hid-sensors/hid-sensor-trigger.c include/linux/hid-sensor-hub.h
2015-02-23HID: hid-sensor-hub: Enhance feature report set APISrinivas Pandruvada1-2/+3
Current API only allows setting one offset in the field. This API is extended to set multiple offsets in the field report. Also update parameters in the users of this API. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-23HID: hid-sensor-hub: Enhance get feature report APISrinivas Pandruvada1-3/+5
Some hid sensor feature report can contain more than one reports. This API can now support receiving multiple values from the feature report. Also update the parameters in the users of this API. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-23HID: hid-sensor-hub: Extend API for async readsSrinivas Pandruvada1-6/+14
Add additional flag to read in async mode. In this mode the caller will get reply via registered callback for capture_sample. Callbacks can be registered using sensor_hub_register_callback function. The usage id parameter of the capture_sample can be matched with the usage id of the requested attribute. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-23HID: hid-sensor-hub: Allow parallel synchronous readsSrinivas Pandruvada1-0/+24
Current implementation only allows one outstanding synchronous read. This is a performance hit when user mode is requesting raw reads of sensor attributes on multiple sensors together. This change changes the mutex lock to per hid sensor hub device instead of global lock. Although request to hid sensor hub is serialized, there can be multiple outstanding read requests pending for responses via hid reports. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-02-17HID: hid-sensor-hub: Correct documentationSrinivas Pandruvada1-0/+5
During changes to the interface, some documentation field comments were missed. Added missing comments. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-05-05iio: hid-sensors: Add API to power on/offSrinivas Pandruvada1-1/+1
Added an API to allow client drivers to turn ON and OFF sensors for quick read. Added data_read as counting varaible instead of boolean, so that sensor is powered off only when last user released it. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-05-05iio: hid-sensors: Add api to get poll valueSrinivas Pandruvada1-0/+2
Added interface to get poll value in milli-seconds. This value is changed by changing sampling frequency. This API allows clients to wait for at least some poll milli seconds before reading a new sample. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-05-05iio: hid-sensors: Convert units and exponentSrinivas Pandruvada1-0/+4
HID sensor hub specify a default unit and alternative units. This along with unit exponent can be used adjust scale. This change change HID sensor data units to IIO defined units for each sensor type. So in this way user space can use a simply use: "(data + offset) * scale" to get final result. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-02-17HID: hid-sensor-hub: Processing for duplicate physical idsSrinivas Pandruvada1-2/+4
In HID sensor hub, HID physical ids are used to represent different sensors. For example physical id of 0x73 in usage page = 0x20, represents an accelerometer. The HID sensor hub driver uses this physical ids to create platform devices using MFD. There is 1:1 correspondence between an phy id and a client driver. But in some cases these physical ids are reused. There is a phy id 0xe1, which specifies a custom sensor, which can exist multiple times to represent various custom sensors. In this case there can be multiple instances of client MFD drivers, processing specific custom sensor. In this case when client driver looks for report id or a field index, it should still get the report id specific to its own type. This is also true for reports, they should be directed towards correct instance. This change introduce a way to parse and tie physical devices to their correct instance. Summary of changes: - To get physical ids, use collections. If a collection of type=physical exist then use usage id as in the name of platform device name - As part of the platform data, we assign a hdsev instance, which has start and end of collection indexes. Using these indexes attributes can be tied to correct MFD client instances - When a report is received, call callback with correct hsdev instance. In this way using its private data stored as part of its registry, it can distinguish different sensors even when they have same physical and logical ids. This patch is co-authored with Archana Patni <archna.patni@intel.com>. Reported-by: Archana Patni <archana.patni@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Archana Patni <archana.patni@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-17HID: hid-sensor-hub: Add selector apiSrinivas Pandruvada1-0/+3
In some report descriptors, they leave holes in the selectors. In this case if we use hardcoded selector values, this will result in invalid values. For example, if there is selectors defined for Power State from OFF to D0 to D3. We can't use indexes of these states if some states are not implemented or not present in the report decriptors. In this case, we need to get the indexes from report descriptors. One API is added to get the index of a selector. This API will search for usage id in the field usage list and return the index. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-12-03HID: hid-sensor-hub: Add logical min and maxSrinivas Pandruvada1-0/+2
Exporting logical minimum and maximum of HID fields as part of the hid sensor attribute info. This can be used for range checking and to calculate enumeration base for NAry fields of HID sensor hub. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-11-02iio: hid_Sensors: fix crash during trigger unregisterSrinivas Pandruvada1-0/+3
We can't store the trigger instance created by iio_trigger_alloc, in trig field of iio_device structure. This needs to be stored in the driver private data. Othewise it can result in crash during module unload. Hence created a trig_ptr in the common data structure for each HID sensor IIO driver and storing here. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-10-01HID: Delay opening HID deviceSrinivas Pandruvada1-0/+18
Don't call hid_open_device till there is actually an user. This saves power by not opening underlying transport for HID. Also close device if there are no active mfd client using HID sensor hub. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-08-26HID: hid-sensor-hub: fix style of commentsAndy Shevchenko1-1/+1
This patch fixes the style of the comments to be like following /* The commentary */ There is no functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-01-06hid: iio: rename struct hid_sensor_iio_common to hid_sensor_commonAlexander Holler1-6/+6
The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to hid_sensor_common. Signed-off-by: Alexander Holler <holler@ahsoftware.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-01-06iio: merge hid-sensor-attributes.h into hid-sensor-hub.hAlexander Holler1-0/+38
The stuff in hid-sensor-attributes.h is needed by every piece which uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible from outside the iio subdirectory. Signed-off-by: Alexander Holler <holler@ahsoftware.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2012-09-06HID: sensors: introduce sensor frameworksrinivas pandruvada1-0/+160
Adding processing for HID Sensor usage table as defined by HID 1.12, Request #: HUTRR39, dated 05 May, 2011. This driver uses HID driver framework to register, send and receive events. This uses MFD framework, so that actual processing for a specific usage id can be done in a different driver. For example an accelerometer driver can be a separate driver and use the interface provided by this driver to register for events. Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>