user/sven/linux.git/include/linux/iio, branch v3.18.22

iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask

2014-11-15T16:04:56Z

The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask in order to retrieve it, that is 0x7F, not 0xCF as it is now. Fixes: ade7ef7ba (staging:iio: Differential channel handling) Signed-off-by: Cristina Ciocan Cc: Signed-off-by: Jonathan Cameron

iio:trigger: modify return value for iio_trigger_get

2014-08-25T20:47:22Z

Instead of a void function, return the trigger pointer. Whilst not in of itself a fix, this makes the following set of 7 fixes cleaner than they would otherwise be. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Cc: Stable@vger.kernel.org

Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-08-06T00:46:42Z

Pull timer and time updates from Thomas Gleixner: "A rather large update of timers, timekeeping & co - Core timekeeping code is year-2038 safe now for 32bit machines. Now we just need to fix all in kernel users and the gazillion of user space interfaces which rely on timespec/timeval :) - Better cache layout for the timekeeping internal data structures. - Proper nanosecond based interfaces for in kernel users. - Tree wide cleanup of code which wants nanoseconds but does hoops and loops to convert back and forth from timespecs. Some of it definitely belongs into the ugly code museum. - Consolidation of the timekeeping interface zoo. - A fast NMI safe accessor to clock monotonic for tracing. This is a long standing request to support correlated user/kernel space traces. With proper NTP frequency correction it's also suitable for correlation of traces accross separate machines. - Checkpoint/restart support for timerfd. - A few NOHZ[_FULL] improvements in the [hr]timer code. - Code move from kernel to kernel/time of all time* related code. - New clocksource/event drivers from the ARM universe. I'm really impressed that despite an architected timer in the newer chips SoC manufacturers insist on inventing new and differently broken SoC specific timers. [ Ed. "Impressed"? I don't think that word means what you think it means ] - Another round of code move from arch to drivers. Looks like most of the legacy mess in ARM regarding timers is sorted out except for a few obnoxious strongholds. - The usual updates and fixlets all over the place" * 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits) timekeeping: Fixup typo in update_vsyscall_old definition clocksource: document some basic timekeeping concepts timekeeping: Use cached ntp_tick_length when accumulating error timekeeping: Rework frequency adjustments to work better w/ nohz timekeeping: Minor fixup for timespec64->timespec assignment ftrace: Provide trace clocks monotonic timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC seqcount: Add raw_write_seqcount_latch() seqcount: Provide raw_read_seqcount() timekeeping: Use tk_read_base as argument for timekeeping_get_ns() timekeeping: Create struct tk_read_base and use it in struct timekeeper timekeeping: Restructure the timekeeper some more clocksource: Get rid of cycle_last clocksource: Move cycle_last validation to core code clocksource: Make delta calculation a function wireless: ath9k: Get rid of timespec conversions drm: vmwgfx: Use nsec based interfaces drm: i915: Use nsec based interfaces timekeeping: Provide ktime_get_raw() hangcheck-timer: Use ktime_get_ns() ...

iio: Use ktime_get_real_ns()

2014-07-23T22:01:45Z

No idea why iio needs wall clock based time stamps, but we can avoid the timespec conversion dance by using the new interfaces. Signed-off-by: Thomas Gleixner Acked-by: Jonathan Cameron Signed-off-by: John Stultz

iio: types: Added support for rotation from north usage attributes

2014-07-20T12:34:45Z

Added the rotation from north usage attributes to the iio modifier enum and to the iio modifier names array. Signed-off-by: Reyad Attiyat Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

iio: core : events ABI for specifying period

2014-07-11T20:20:59Z

The iio sysfs ABI defines a way to specify period for roc and thresholds. What: /sys/.../events/in_accel_x_thresh_rising_period What: /sys/.../events/in_accel_x_thresh_falling_period what: /sys/.../events/in_accel_x_roc_rising_period What: /sys/.../events/in_accel_x_roc_falling_period But there is no way to add period with the current event info enum. Added IIO_EV_INFO_PERIOD and corresponding string. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

iio: st_sensors: add devicetree probing support

2014-07-11T20:09:49Z

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 Cc: Denis CIOCCA Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

iio: adis: Switch sampling frequency attr to core support.

2014-07-07T08:44:17Z

By using the info_mask_shared_by_all element of the channel spec, acce to the sampling frequency becomes available to in kernel users of the driver. It also shortens and simplifies the code. This particular conversion was made more complicated by the shared library and the fact that a number of the drivers do not actually have support for setting or reading the sampling frequency. The hardware, in those cases investigated supports it. It's just never been implemented. Signed-off-by: Jonathan Cameron Reviewed-by: Hartmut Knaack Acked-by: Lars-Peter Clausen

iio:st sensors: remove custom sampling frequence attribute in favour of core support.

2014-07-07T08:39:57Z

This allows in kernel client drivers to access this Signed-off-by: Jonathan Cameron Cc: Denis Ciocca Reviewed-by: Hartmut Knaack

iio: accel: kxcjk1013 3-axis accelerometer driver

2014-06-14T16:10:21Z

This patch adds IIO driver for KXCJK 1013 triaxis accelerometer sensor. The specifications for this driver is downloaded from: http://www.kionix.com/sites/default/files/KXCJK-1013%20Specifications%20Rev%202.pdf Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron